Argument unpacking?

Dave Herman dherman at ccs.neu.edu
Sun Nov 12 19:16:13 PST 2006


> ES3 has little to do with it.

It does insofar as your point was that we lose something by making 
`apply' harder to type: since `apply' has never had a type, we haven't 
lost anything per se.

But I see what you're saying: it's an "opportunity cost" since it 
becomes less ES4-typeable.

>     function apply(target:Object, args:Array):*;

..which is a pretty weak type.

A more precise type for such a function would be something like:

     function.<T1, ..., Tn, Trest, Tres>
         apply(fun:function(x1:T1, ..., xn:Tn, ...rest:Trest):Tres,
               args:[T1, ..., Tn, Trest]):Tres

We can almost express this type in our proposed type system (I think I 
was wrong about this being a dependent type). It's just a generic type, 
but one with a variable number of type parameters, which we can't handle.

> And there would be compile-time and run-time errors if args was not an
> Array. With P T Withington's suggestion, it would be:
> 
>     function apply(target:Object, ...rest):*;

[As a curious side note: we could *almost* express the type of the Lispy 
version of `apply'--i.e., a sequence of arguments of type * followed by 
a single argument of type Array--by giving the rest-args a structural 
array type; see

http://developer.mozilla.org/es4/proposals/structural_types_and_typing_of_initializers.html

for a sketch. That page doesn't explain very much but the idea is that 
array types can have finite heterogeneous prefixes--e.g. the type of 
arrays whose first element is a Boolean, second element is a String, and 
remaining elements are ints. So we can express the types of a finite 
prefix followed by an unbounded suffix, but we can't express the types 
of an unbounded prefix followed by a finite suffix, which is what we 
would need in this case.]

> in which case, there would be no compile-time errors and run-time
> errors would depend on the implementation.

Even if it doesn't have a precise type, the library spec can still 
impose constraints on implementations so it isn't 
implementation-specific. You're right about compile-time errors, though.

> Agreed that apply() is intrinsically dynamic, but there can be some
> constaints on how it is used, and those can be enforced by the
> language.

Sure, although it's a modest amount of checking. The trade-off is 
between a rather minor convenience in error checking versus a similarly 
minor convenience in flexibility of use.

Dave



More information about the Es4-discuss mailing list