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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
