implementation dependencies (was Re: ES4 work)

Michael O'Brien mob at
Wed Feb 20 22:58:36 PST 2008

Comments below:
> Going further, I have mentally considered the language as providing 3 
> "big" categories of enhancement: fixtures, types, and namespaces. I 
> think that within -- and possibly between -- these groups there are 
> dependencies. For example, we can consider these "levels" of 
> type-implementation:
>    TY-VAL: a runtime representation of types exists, and values have
>            a pointer to their type
>    TY-PROP: properties can be annotated with types, and a dynamic
>             check is made when an assignment is made
>    TY-DEF: type-aliases ("type T = ...") can be defined
>    TY-STRUCT: the full structural type grammar exists (object types,
>               array types, function types)
>    TY-NULL: the nullability extension to the type grammar exists
>    TY-NOMINAL: class and interface types exist, with a hard-coded
>                subtype lattice
>    TY-PARAM: the parametric type system exists
>    TY-LIKE: the 'like' types exist
>    TY-STRICT: approximate static checking of types
>    TY-REFLECT: meta-objects exist and can be acquired with typeof
> This is a partial dependency list. You need at least TY-VAL to do 
> TY-PROP, but it's probably possible to implement any combination of the 
> remainder once you're at TY-PROP. You could also stop *at* TY-PROP, only 
> permitting users to denote the ES3 types (prims and objs). Though IMO 
> this would be silly.
We began and have a fairly complete TY_VAL and TY_PROP. Next we did 
and TY_REFLECT. We are missing DEF, STRUCT, NULL, PARAM and LIKE.  We 
have partial
> We can also consider "levels" of namespace-implementation:
>    NS-VAL: a runtime type "namespace" exists, and has some nonempty
>            population
>    NS-PROP: every property has a namespace and namespace references
>             can be used in reference expressions like obj.ns::prop
>             and ns::lexref
>    NS-USE: the "use namespace" and "use default namespace" pragmas
>            automatically qualify definitions or references
>    NS-DEF: "namespace" declarations are accepted and new namespaces can
>            be defined through them, either anonymous or with strings
>    NS-CLS: classes (and interfaces?) define their own namespaces for
>            conventional OO visibility control
>    NS-PKG: the "package" construct exists for automatically defining
>            namespaces
> Similarly, this list is more linear at the top than the bottom: NS-PROP 
> and NS-USE require NS-VAL, though one could stop there with (perhaps) a 
> fixed population of namespaces. The remaining 3 are mostly orthogonal: 
> you could for example stop implementing with NS-DEF and ignore classes 
> and packages, and still have a useful system. Or do NS-CLS alone and 
> ignore NS-DEF, using namespaces only to model class-visibility issues.
I think this is very much an all or nothing. It is hard to separate out 
these from each other.
We started with NS_DEF, NS_VAL and NS_PROP. NS_USE was easy
NS_USE is pretty easy once you have NS_VAL and NS_PROP. NS_PKG is 
essential if you
are going to handle package qualified variables and avoid name 
collisions. So I'd imagine it
would be hard to have a cohesive whole without doing all these items.
> All the type and namespace issues depend, however, on fixtures. We are 
> some ways towards "proving" that fixtures-in-absence-of-namespaces are 
> equivalent to the "dontdelete" property attribute (see ticket #233, 
> but if you have namespaces there 
> appears to be a requirement to be modeling fixtures, to run the 
> multiname algorithm properly. Fixtures are sort of "super-dontdelete" 
> properties -- those that can safely be early bound, in addition to not 
> being deletable -- and it's hard to make much use of the namespace or 
> type systems without them.
Agree. We had fixtures first and retrofitted namespace (which I would 
not recommend). Namespaces
are so foundational, you need to design them in at the start. Otherwise, 
there is a lot of rework.
> Re-encoding the ES3 primitives as classes, and the new classes like map, 
> vector and the meta objects, all require a fair amount of the TY and NS 
> work: at least TY-NOMINAL, TY-PARAM and NS-CLS (I think).
Looking at the builtins, I can't imagine how you could do them without 
namespaces. They
are a vital solution to various name lookup and collision problems.
> Finally there is a category I left off the above elaboration, mostly 
> because it is under-developed in the RI: control mechanisms. There are 
> dependencies between tail calls, generators and stack inspection, and I 
> can't say I fully understand the dependencies nor the impact they have 
> on the rest of the implementation.
There are a whole raft of implementation "toughies" that will vary a bit 
from implementation to
implementation. We have spent a lot of time trying to get ES4 to be 
small and fast. But there is
a long, long way to go.

> -Graydon
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at

More information about the Es4-discuss mailing list