Merge: Better varargs
authorJean Privat <jean@pryen.org>
Fri, 17 Oct 2014 00:20:53 +0000 (20:20 -0400)
committerJean Privat <jean@pryen.org>
Fri, 17 Oct 2014 00:20:53 +0000 (20:20 -0400)
since their introduction in Nit, varargs had a quick and dirty implementation.
They where implemented with a complex path in the low-level parts of engine instead being implemented at  the AST level as it should be: varargs is more a syntactic sugar than something else.

Thus this PR changes the implementation of varargs in the engines.
This rationalize the `varargize` methods and simplify the code for low-level part (and also solve some bugs)

Additionally, the reverse-vararg, already accepted by the parser but unused until now, is implemented.
The principle it to pass an array where a vararg is expected.
Because of static ambiguities, the array passed as-is must be annotated with an ellipsis (`...`).

~~~nit
fun foo (xs: Object...) do print x.join("-")
foo(1,2,3) # prints "1-2-3"
var a = [1,2,3]
foo(a...) # prints "1-2-3"
foo(a) # pass `[a]`, a new array with a single element `a`, to foo, thus prints "123"
foo(1...) # Static Type Error: expected Array[Object], got Int.
~~~

Still, I think that error messages should be improved (cf. #98) but this seems to need some additional work in the error infrastructure.

A remaining question is what is the best acceptable type passed.
In the proposed implementation, the reverse-vararg must be a compatible Array (so a Sequence or a List are not accepted) and is given as is to the real method, that is allowed to modify it.
Should we change the type on a vararg to be a Sequence, a SequenceRead, of even a simple Collection ?

Pull-Request: #827
Reviewed-by: Lucas Bajolet <r4pass@hotmail.com>
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>

1  2 
src/compiler/abstract_compiler.nit
src/interpreter/naive_interpreter.nit
src/semantize/typing.nit

Simple merge
Simple merge
Simple merge