thoughts the (re)organization of the specification?

David Herman dherman at
Fri Nov 2 23:32:58 PDT 2012

It's always fun to think of ways to make a better spec. But also good to keep in mind the risks:

- The spec is not in any machine-readable form, meaning it's neither testable nor formally verifiable in any way. This means refactoring must be done carefully, since it can't be verified.

- The more radical the changes, the more risk of introducing bugs, ranging from minor to deep/logical. Even minor bugs risk interoperability problems as implementers diverge in interpretation.

- Major rejiggering of the spec could result in difficulties in tracking implementation conformance, as implementations are often written to follow the spec structure, and often have inline comments referencing their corresponding ES3/5 semantic steps. But I chatted with Jason Orendorff and he wasn't too concerned about Allen's suggestions.

- The more radical the changes, the more editorial work it takes. We're on a schedule, we can't fork Allen, and anyway it'd probably be hard to have multiple authors doing serious concurrent work within Word.

That said, Allen's the best judge of what organizational changes he thinks need to be made and what he can reasonably accomplish within our time frame. I love the changes Allen made in ES5 (e.g. the declarative environment frames), and I'm happy to see evolutionary improvements to the structure of the spec.


On Nov 2, 2012, at 9:55 PM, Axel Rauschmayer <axel at> wrote:

>> Have you considered to split this spec into two part: one is for language implementer and the other is for language user?
> Interesting idea! You could argue that writing the second part is the job of JavaScript book authors.
> -- 
> Dr. Axel Rauschmayer
> axel at
> home:
> twitter:
> blog:
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list