Polymorphic literals

[jpacik]

This epic will be complete when we can use integer literals in different contexts in a type safe way across flux. For example

a = 1
b = a + 1
c = a + 1.1

Polymorphic literals must also be supported in lambda functions. The following query should work regardless of whether r._value is a float or an int

|> map(fn: (r) => ({_value: r._value + 1}))

[nathanielc]

Related child issues #3347 #3337 #476 #3389

[Marwes]

There seems to be two PRs to attempt to implemented this (#3360 and #3252) however I would argue that how they work at the interpreter level is flawed, or at least incomplete. Their implementation avoids converting the literal to the actual type at creation and just keeps it as an integer value. Operators like +: float -> float -> float are then overloaded with functions that also accept integers in their place to handle the values created by these literals. This is very error prone as forgetting to include some combination will result in a runtime panic but even with all operators covered you will also have to deal with these integers in functions defined in go etc.

To make this sane I think the interpreter needs a single, generic number type (ala python) or we do it the statically typed way and implement monomorphization, or dictionary passing so that we know how to convert the integer literal at its creation.

(One way to think of this is that the current implementation of constraints cheat a bit by utilizing the dynamic type in the interpreter to choose which implementation of + etc to call. This only supports generic functions where the type is known in the argument of the function + : a -> a -> a, but falls apart when only the output knowns fromInteger : Int -> a)

[github-actions]

This issue has had no recent activity and will be closed soon.