ES4 implementation process, teams, and meetings

Graydon Hoare graydon at
Thu Feb 21 16:34:28 PST 2008

Maciej Stachowiak wrote:

> I don't think the sets are disjoint, but they are not identical either.

Agreed. I am trying to arrive at an understanding of which camp Apple 
aspires to ("designer", "implementor" or both) and in particular how you 
wish to enact that role. Any Rhino hackers (or other implementors) may 
also wish to chime in. It sounds to me like "not having anything to do 
with the RI" is characteristic of how you wish to participate. Is this 

> I don't think foundational documents are what we need to implement 
> specific features. What we need are rough cut but accurate specs for the 
> features to implement. I don't think SML + trac is a form that anyone 
> here can easily understand.

Ok. Some of the features are deep and some are shallow. Many of the 
shallow ones are not in much flux, do not require much insight, and are 
well-described by the "proposals" on the wiki. You could readily show 
one to an engineer and have them implement, say, destructuring 
assignment, triple quotes, date and time extensions, regexp extensions, 
a hashcode function, getters and setters, block expressions (let 
expressions), enumerability control, String.prototype.trim, expression 

Others, as you've noted, require some clean-up / consolidation to be 
brought into line with tickets. Decimal and numerics turned out to be an 
ongoing source of trouble, as did tail calls. We're still discussing 
these. We can probably do this in parallel with your team implementing 
the ones that are more stable.

The thing we don't have "feature sketches" for are deep, systemic issues 
that affect the whole language: types, fixtures and namespaces. Also the 
rules governing packages, classes and interfaces. These came in 
"implicitly" from AS3, and the type system in particular has been 
modified extensively: Cormac's paper and the code in type.sml is 
probably the best we have to describe the intended type system. This is 
what I meant by "foundational" documents. Do you still feel that they 
are not needed?

> Well, neither I nor anyone on my team know SML. Nor do we know the 
> internals of the reference implementation, what aspects of it are 
> normative, which are implementation details, and which are considered 
> bugs and are intended to change. Nor would I know where in the RI to 
> look to understand how to implement particular features. For example, 
> "let" binding was raised as an example of a possible early 
> implementation feature. I don't know where in the ~40 klocs of SML in 
> the repository I should look.

I am trying to give you a guide, but am unsure if you want this form of 
guidance. SML is a small functional language, and we use mostly 
applicative style. Nothing crazy.

Here is a general rule for researching an aspect of the language: start 
by identifying the AST node for a feature; if you can't find it by 
guesswork and reading ast.sml, ask someone on IRC or here. Then 
depending on what you want to do for that feature, read the parser.sml 
function that produces that node, the defn.sml function that elaborates 
it, the type.sml rule that checks it, or the eval.sml rule that 
evaluates it.

It would also be good to read some of mach.sml to familiarize yourself 
with the runtime machine model eval.sml manipulates, if you're 
investigating a runtime entity. The interesting types are VAL, OBJ, 

> If learning SML is really a prerequisite to being one of the early 
> implementors, then I am not sure anyone working on WebKit/JavaScriptCore 
> is qualified, which is a pity. If learning SML is a prerequisite to 
> understanding the finished spec, then that will be a pretty high barrier 
> to entry for even non-early implementors.

It certainly will not be a requirement for understanding the finished 
spec, though depending on whether any pieces of the code make it in as 
informative annexes, it may help. It *is* currently a requirement for 
understanding the RI, which the committee agreed to work together on 
last year rather than drafting "formal" pseudo-assembly / pseudo-english 
language we could neither execute nor even automatically check for typos.

So far some members of the committee have taken to working on it, while 
some have not. Are you interested in working on it, as part of Apple's 
active participation in the process? Or learning to read it? Or is it a 
completely opaque non-sequitur from Apple's perspective?

The idea here -- and feel free to say it's a bad idea or you disagree! 
-- is that a very high level programming language carries a *different* 
mixture of risks than very low level natural language, and possibly a 
more desirable mixture. In particular, as you say, it risks 
overspecifying and using unfamiliar technical notation; but the risks of 
natural language (being logically contradictory and underspecifying) are 
significant too!

> I tried reading over some of the SML files you mentioned and without 
> context or knowledge of the language I could not make heads or tails of 
> them. The first function I read was extractRuntimeTypeRibs and I can't 
> tell what it's doing or how (or what aspects of the ES4 language it 
> relates to).

It is a bottom-up program, so most modules start with support functions 
like that one and proceed to higher and higher level details: lost 
readers should probably read bottom-to-top. And it is best to start with 
the ast, since the interpreter is a simple tree-walker. The machine 
model is in mach.sml. The evaluation rules are in eval.sml.

If you want to know how let binding works, for example, I can readily 
guide you: the ast nodes in ast.sml are LetStmt and LetExpr. They are 
built by parser.sml, by the function letStmt, and their definition is 
reduced to a "head" (set of fixtures and initializers) by defBlock in 
defn.sml. They are evaluated by the evaluator functions evalLetStmt and 
evalLetExpr, in eval.sml.


More information about the Es4-discuss mailing list