need some clarification on compile-time type vs. run-time type

Graydon Hoare 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
> background.

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.

-Graydon




More information about the Es4-discuss mailing list