ES4 implementation process, teams, and meetings

Graydon Hoare graydon at mozilla.com
Thu Feb 21 17:03:29 PST 2008


Maciej Stachowiak wrote:

> What I am asking is this: for each proposal where you'd like early 
> implementations, before implementation commences please write down 
> enough information about that proposal in some reasonably understandable 
> form to represent the current shared understanding of the 
> insiders/old-timers. 

Ok. Understand though that you're asking for a bit of a change to the 
game plan. That's a reasonable demand but the "early-early" 
imlpementations (RI, futhark, spidermonkey, esc) were all done by people 
who *did* have that shared understanding (through earlier participation 
and discussion) and *did* find the SML we were all working on 
"reasonably understandable".

So presenting yourself as a participant with neither of those supports 
in place, you're sort of walking into a room, kicking the legs out from 
under a table and asking why it's suddenly on the floor. We need to 
revise the strategy a bit to help for your case, if we can't rely on 
those. Please try to be patient if this takes some time; none of us had 
put "write pre-impl docs" in our current work-assignment schedules. 
We'll need to make room to do it. I can probably dedicate a month of 
nearly-full-time energy to this starting in the first week of march. 
Soon enough?

(Also note that about half of the RI is written in ES4, not SML, and 
that is surely understandable to your team with minimal effort)

> I have no idea what changes aren't in trac. In the past I've asked 
> questions on #jslang or elsewhere about particular proposals (such as 
> the parametric types proposal) and been told that many things about it 
> had been changed, and the person telling me wasn't sure if all these 
> changes had trac tickets, or if so, what they were.

Unfortunately parametric types are one of the cases where you are 
stabbing at both a terribly in-flux and terribly deep part of the 
language; they only make sense in the context of types in general, and 
the *entire* type system has been in flux for quite some time. I believe 
it is stable now, and I believe the way to understand it is to read 
Cormac's paper first and type.sml second, ignoring much of the residue 
in the wiki. I'm sorry about this. A consolidated write-up would be 
good, I agree.

Part of what I was trying to get at by describing dependencies was that 
you don't really need to understand the entire type system to get a 
little miniature version of it hobbling along. The initial task to ask 
one of your engineers to do is "give each property and each value a 
pointer to a runtime-defined 'type' (TBD) and run a function that checks 
those 'match' (TBD) when someone performs an assignment". Then start 
enhancing the meaning of "type" and "match" as you learn more about 
them: mbedthis (and the RI) started with simple nominal types (classes 
in a hierarchy) and worked out from there.

> It really seems to me like in many cases there is a shared understanding 
> among many of the insiders that is only recorded inside people's heads. 
> Maybe that's not right, but that is certainly the impression I've gotten 
> every time I have asked questions about where something is documented.

This depends significantly on the feature in question. For types, and 
discounting both Cormac's paper and the RI as "something you can't 
extract the desired degree of meaning from", this is probably true. 
There's not a laid-out plan of the full type system in english alone. I 
don't know if you like reading LaTeX-y academic type judgment rules more 
than SML :)

For simpler features, I think this is an over-generalization. With some 
simple markup about currentness, some of them are implementable as-is. 
But hopefully we can patch up the worst cases and/or mark the stable and 
easy pieces quickly, so you can make progress.

> Great, if some proposals are accurate and up to date enough to drive an 
> initial implementation, then my concern is addressed for those features. 
> But I don't know how to tell which ones those are. Is there a list of 
> which proposals are up to date?

No. You're right that we should sort them or mark their outdated-ness 
and revise them. This may cover features that stand as proposals. For 
deeper cross-language issues (say "how classes work"), it is not a 
matter of bringing a page up to date as writing one in the first place. 
Nobody "proposed" them since they were inherited from AS3. We may get to 
writing pre-implementation guides to these too, but it too will take time.

> Furthermore, this won't help when it comes time to implement proposals 
> that *aren't* up to date. All I'm asking is that they be brought up to 
> date first.

A reasonable request; one we haven't focused energy on lately.

-Graydon



More information about the Es4-discuss mailing list