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