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 _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
