need some clarification on compile-time type vs. run-time type
graydon at mozilla.com
Fri Nov 9 15:20:41 PST 2007
Yuh-Ruey Chen wrote:
> I've been experimenting with the ES4 RI lately. I've discovered that the
> following doesn't work:
> x = int;
> 10 is x; // error
> 10 to x; // error
> 10 cast x; // error
> var y: x; // error
> Of course, if I had used |type x = int|, it would work. Is this because
> x is not a compile-time type?
Roughly. Some refinements to terminology: there are no "compile-time
types" or "run-time types". There are types (and interfaces, and
classes). They get bound to property names. Some of those properties are
fixed, some are not. Some fixed properties are additionally constrained
to hold types, classes or interfaces. Some are not.
Your example fails because x is not a fixed type-property. Properties
introduced by 'type', 'class' or 'interface' are.
Type names in type expressions only consult fixed type-properties,
because we want evaluation of type expressions to be as predictable as
possible. There are only ever 2 results to evaluating any type expression:
#1 full evaluation to a specific "ground" type term
#2 suspended partial evaluation due to incomplete information
The flow of program control may affect which of these two results we
get, and it can provide new information to restart a suspended
evaluation -- by loading new code containing type definitions using
'eval', for example -- but it *cannot* invalidate a result of an
evaluation. Types never need to be "re-evaluated" to reflect "mutation"
in their environment. The evaluation of type expressions can (and
should) memoize types.
I find it a bit odd that |10 is x| didn't
> work while |10 instanceof x| does work, considering that |is| is touted
> as the successor to the |instanceof| operator. Or is |instanceof| the
> run-time counterpart to |is|? Then should |instanceof| work on
> everything that |is| can work on?
instanceof consults the prototype chain. It happens to be the case that
for classes, the prototype chains are arranged to follow the class
inheritance hierarchy. But there are a variety of differences; for
example, "x instanceof z" may return false in cases where "x is z"
returns true (if z is an interface, say).
> These distinctions between compile-time types and these run-time types
> (e.g. x in the above example) are subtle and confusing. I figure that
> all these distinctions will trip many ES4 newcomers coming from an ES3
Perhaps. It's not clear what else we ought to do; the alternatives we've
explored sound worse. Any suggestions?
> BTW, it doesn't seem like the "like" and "wrap" operators are
> implemented in the RI yet, so I couldn't really test out structural types.
No, they are not implemented yet. The implementation of the type system
is still somewhat shaky, unfortunately. I am working on it presently.
More information about the Es4-discuss