privat/nit — pull request #827 by privat (2014-10-15 15:36:58+00:00)
Title: Better varargs

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 that 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 Collection ?