Michael O'Brien wrote: > As a solution: I think we need an intermediate step. Not a spec, but > some detailed design notes. Lar's document was a good > overview, but drill down on exactly how the mechanisms are meant to work > would be very helpful to broaden the base of > implementations. Some examples of the things I'd like to see are: > > * Exactly how the scope rules work for various constructs > * Order of initialization > * More detail on namespace lookup rules > * More detail on unqualified variable lookup > * Type matching rules and conversions > * More detail on nullability > > But there is a lot more. We can do this via Q&A, which is what we have > been doing, but it is hard and requires quite a bit of sleuthing.
I see. I would have hoped these would be visible more or less directly by inspection: * the scope rules and initialization order of each construct are elaborated production-by-production in eval.sml * the namespace lookup scheme is elaborated in multiname.sml, fixture.sml and defn.sml * the unqualified lookup rule starts in eval.sml (evalLexicalRef -> evalRefExpr -> resolveOnScopeChain -> Multiname.resolve) * the type matching and conversion rules begin with runtime judgments in eval.sml (evalBinaryTypeOp) and then transition to type.sml for their type-term-specific parts (groundMatchesGeneric and findSpecialConversion) * the nullability system is more spread out, covering some part of the type normalizer in type.sml and some part of the property allocation scheme in eval.sml I'm sad to hear that the RI was not sufficiently clear on these points, but I guess this was a risk in the choice of language; SML is terse but also not always familiar. Some of the SML code can be "lowered", via a prototype converter I have written, to english. Notational details are erased but the names and structure is preserved. Would this be useful? Another possibility is to expand the internal commentary of the RI, or write some sort of study guide. I'm hesitant to commit to "yet another bit of plain english docs", both because everyone who could write them already has lots to do, and because there is nothing guaranteeing that such docs remain current or honest. As we've seen, it's easy for an english doc -- such as a wiki page -- to drift into obsolescence if there's not constant energy spent updating it. -Graydon _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss