On Feb 21, 2008, at 4:34 PM, Graydon Hoare wrote:
> 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.
Apple is not monolithic. Some of us hope to participate more in the
design process, but it's pretty likely that people who don't deeply
involve themselves in the design process will do a lot of the
implementation work. Those people who are implementing need to have
something to follow.
> 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 correct?
We're unlikely to have much interest in working on implementing the
RI. We have a small team and our hands are full implementing our own
JS engine (and the rest of the browser engine). And we think that
ultimately implementing a production-quality implementation in our
engine is more valuable.
While we try to do our part to help with development and validation of
important web standards, learning a new programming language and
coding in it is a pretty high barrier to entry. Is that really the
only way to meaningfully participate in the process?
As for reading the RI, it seems a lot harder to understand than specs
written in prose. As far as I can tell, only people who have coded
significant portions understand it.
>> 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 closures.
Great, can we start recording this list somewhere? Perhaps part of
breaking down features and figuring out the dependencies should be
recording which features have an up to date and accurate wiki proposal.
> 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.
A clear list of proposals that are clearly not ready would be valuable
as well. So let's also start recording this list.
> 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?
Documentation will certainly be needed when it comes time to implement
said features.
>> 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, VAL_TAG, MAGIC, SCOPE, REGS, PROP_STATE, TEMP_STATE,
> TEMPS, PROP, PROP_BINDINGS.
This information is helpful, but it barely scratches the surface of
what it would take to understand the RI.
>> 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!
On the one hand, it's useful to have a reference implementation to
validate what is being done, explore ideas, have something to test and
compare against, etc.
But yes I think it is an incredibly bad idea for the only
specification to be a computer program. It's not approachable. I don't
think I could quickly grok a program of this complexity even in a
programming language I am familiar with. And by its nature it does not
very cleanly partition separate concepts. For example, below you
pointed me to 6 places in the code for "let" statements, and I doubt
that reading those functions alone will be enough to understand it. So
in practice, I don't think there is any way to understand "let" in
detail without asking you or another expert on the RI.
>> 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.
I asked someone who knows SML to look at it and he found the code
pretty opaque as well, perhaps due in part to the very terse variable
names and occasionally obscure concepts. (I still don't understand
what a "runtime type rib" is, and searching for other references in
the file does not elucidate, so I'm not sure reading backwards would
help.)
> 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.
"let" was meant to be an illustration that it's prohibitively
difficult to get the needed info without having inside knowledge. If I
were to generalize this approach to help someone understand another
ES4 feature, I would probably just say "ask Graydon". Is it truly
acceptable to have a spec where that's the easiest way to understand it?
Regards,
Maciej
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
