implementation dependencies (was Re: ES4 work)

Graydon Hoare graydon at mozilla.com
Tue Feb 19 18:39:14 PST 2008


Jeff Dyer wrote:

> The basic workflow:
> 
>   Proposal -->
>      Implementation -->
>         Feature spec -->
>            Feature review -->
>               ES4-RI -->
>                  ES4 spec -->
> 

One thing that springs to mind when looking at this is that the 
proposals -- that is, really, the "features" to be implemented -- have 
implementation dependencies that need to be reflected in any work plan.

I pointed this out in the phone meeting today and was asked to outline 
some of the implementation dependencies I've noted while working on the RI.

I think a certain number of features are mostly-independent of all 
others, so they can be cleared off first: enhancements to unicode and 
regexps, slice syntax, string.prototype.trim, the global object, triple 
quotes, line terminator normalization, improvements to Date, the set of 
"pure bug fixes" in ES3, expression closures, let-binding, fixes to the 
arguments object, control of enumerability, destructuring assignment. 
These are all essentially stand-alone and several have already shipped 
as vendor extensions to ES3.

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 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.

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, 
http://bugs.ecmascript.org/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.

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).

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.

-Graydon




More information about the Es4-discuss mailing list