public final class Array[%ElementType] : Iterable[ElementType] { // A function which takes a variable-length list of arguments and // returns an array of those arguments. static def of(elements:ElementType...) -> Array; } def test() { let a = Array.of(1, 2, 3); }
As you can see in the example, the type of the array is deduced from the arguments to the static method 'of'.
Having got this working, I've now implemented array literals - so [1, 2, 3] is merely syntactic sugar for Array.of(1, 2, 3).
The reason for doing it this way is that my type inference engine works on function calls - it tries to find a common ground between the parameters of the function and the arguments of the call, binding template parameter substitutions and adding implicit casts as needed. While I could extend the engine to work on other kinds of language constructs, that would make it more complicated - it's much simpler to transform the other language constructs into function calls. Fortunately, pretty much everything can be transformed into a function call. Thus there is no special logic for, say, arithmetic operators to insure that both terms are promoted to the least common type - instead, we just convert arithmetic operators into function calls, and let the overload resolution process do it's work.
Of course, once the type resolution is done, many of those calls will be replaced with code that is generated inline, so it's not like we are paying any overhead for this.
Having got this working, I've now implemented array literals - so [1, 2, 3] is merely syntactic sugar for Array.of(1, 2, 3).
The reason for doing it this way is that my type inference engine works on function calls - it tries to find a common ground between the parameters of the function and the arguments of the call, binding template parameter substitutions and adding implicit casts as needed. While I could extend the engine to work on other kinds of language constructs, that would make it more complicated - it's much simpler to transform the other language constructs into function calls. Fortunately, pretty much everything can be transformed into a function call. Thus there is no special logic for, say, arithmetic operators to insure that both terms are promoted to the least common type - instead, we just convert arithmetic operators into function calls, and let the overload resolution process do it's work.
Of course, once the type resolution is done, many of those calls will be replaced with code that is generated inline, so it's not like we are paying any overhead for this.
No comments:
Post a Comment