I've been thinking about the problem of passing a Sequence of values to a sequenced parameter in Ceylon (a varargs
parameter in Java terminology). Consider:
void print(Object... objects) { ... }
String[] words = {"hello", "world"};
print(words); //what does this do?
Does the second line mean that we're passing a single Sequence<String> to print(), or two Strings? Java behaves very strangely in this situation:
//Java:
print(new String[]{"hello", "world"}); //passes two Strings with a compiler warning asking for an explicit cast to Object[]
print(new Object[]{"hello", "world"}); //passes two Objects with no compiler warning
print(new String[]{"hello", "world"}, new String[]{"hello", "world"}); //passes two String[] arrays as varargs!Ugh!
Things gets even a little more complicated when you have a generic method like this:
T? first<T>(T... objects) { ... }
String[] words = {"hello", "world"};
first(words); //what type should be inferred for T?
This really starts to screw up my beautiful clean type argument inference algorithm! Which is why this issue is coming up now - it's a corner case that I only noticed once I actually implemented generic type argument inference in the type analyzer.
So I think we need to make you explicitly specify what you mean when you pass a sequence of values to a sequenced parameter. I have a couple of ideas about how to do this.
Solution 1
First solution, kinda indirectly inspired by groovy, would be a special syntax in the positional parameter method invocation protocol.
String[] words = {"hello", "world"};
print(words); //pass a single String[]
print(words...); //pass two Strings
String[]? words2 = first(words); //infers T = String[];
String? word = first(words...); //infers T = String
I think this reads fairly naturally. The downside is it's a special-purpose kind of punctuation that needs to be specially explained in the specification.
Solution 2
Second solution is to introduce a special type (a subtype of Sequence) to represent a package of sequenced arguments. Call it SequencedArguments. Then, with a little helper method spread() that wraps up a Sequence as a SequencedArguments, the syntax would look like:
String[] words = {"hello", "world"};
print(words); //compiler automatically produces a SequencedArguments<String[]>
print(spread(words))); //explicitly pass a SequencedArguments<String>
String[]? words2 = first(spread(words)); //infers T = String[];
String? word = first(spread(words)); //infers T = String
This is a little more verbose, but reasonable. It also makes the specification easier to write.
Solution 3
Solutions 1 and 2 can be combined very elegantly. We can define:
- T... means SequencedArguments<T> for any type T
- e... means SequencedArguments(e) for any expression e
So T... is just a type name abbreviation like T[] and T?, and e... is just an operator expression. We end up with exactly the same syntax as Solution 1, but with the semantics of Solution 2.
I think this works out, and is very much in the spirit of the language. On the other hand, if T... is just an ordinary type declaration, I don't know how we can go about enforcing that a sequenced parameter must be the last parameter in a parameter list. I kinda like the fact that this is an error:
void print(Object... objects, OutputStream stream) { ... } //compile error?
WDYT? Does print(words...) read well to you guys, or does it feel arbitrary?
P.S.
Let's not confuse this too much with the idea of applying an operation to a tuple of arguments like what you can do in functional languages and dynamic languages. This is superficially similar, but not quite the same.
UPDATE
A reasonable syntactic variation that perhaps reads somewhat better would use all as a keyword:
void print(Object all objects) { ... }
print(words); //pass a single String[] print(all words); //pass two Strings
I could probably get into this if I didn't just hate the idea of keywordizing the very useful word all
.
