I wonder if you can answer some of the metacircularity concerns by defining the necessary parts using operational semantics, as in http://jssec.net/semantics/sjs.pdf .
As an aside, has anyone actually attempted to formally document the necessary kernel subset (apart from the above paper)? -- Dirk On Mon, May 17, 2010 at 4:03 PM, Graydon Hoare <[email protected]> wrote: > 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 > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
