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
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
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.
More information about the Es4-discuss