On 17/05/2010 2:48 PM, Douglas Crockford wrote:
I would like to see the next edition of the specification use the
ECMAScript language to describe the ECMAScript language. I think this
would significantly improve the likelihood that a programmer could
correctly understand ECMAScript by reading the standard. I think that
would make the web a better place. A strawman is in the wiki.
http://wiki.ecmascript.org/doku.php?id=strawman:specification_language
Some thoughts on this (as one of the authors of the ES4 RI):
- The circularity hazards you mention are real, and were a large
reason why we "bottomed out" in SML. Unless you're expecting users
to take the fixpoint of the spec or something (which may not even
be unique) you will probably need to draw a line around a kernel
language that you define "some other way". SML has a denotational
semantics, which is why we picked it. I'm not suggesting you pick it
again (plenty of problems arose; mostly cultural) but I think you'll
get the most mileage here when describing the standard libraries,
and possibly the front-end, rather than the core concepts like
"evaluate expression" or "look up name".
- There is already a fair quantity of code for both those bits
(library and front-end). ES4 libraries were being written in ES4;
Narcissus has a decent front-end and Mozilla has people working on
it still. Consider cribbing from these.
- Another serious hazard (and strong-ish argument for drawing a line
around a non-self-defined kernel language) is the risk of
over-specification. It's easier to avoid in library code, much
harder when dealing with bits of the most-primitive semantics, which
differ quite a lot between different implementations of ES.
- Be careful with legibility. Another (secondary) reason we settled on
SML is that it presented what we considered at the time to be a
relatively clean typographic quality and can be rendered as "not
very much like source code" with a certain amount of mechanical
translation and/or marked redaction work. We were repeatedly
warned that we would need to have a "natural language" translation
produced from the executable steps, on the basis that ISO and/or
ECMA would reject standards containing source and that "IP issues"
would substantially cloud and possibly derail the process if any
source code was proposed. Find out if this is a real problem before
you go too far down this road.
-Graydon
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
