ES4 implementation process, teams, and meetings
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
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
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.
(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.
More information about the Es4-discuss