thoughts the (re)organization of the specification?

Michael Dyck jmdyck at
Sat Nov 3 11:28:56 PDT 2012

David Herman wrote:
> On Nov 3, 2012, at 12:16 AM, Michael Dyck <jmdyck at> wrote:
>> David Herman wrote:
>>> - The spec is not in any machine-readable form, meaning it's neither
>>> testable nor formally verifiable in any way.
>> I'm working on transforming the spec into a machine-friendly form.
>> (That's how I come up with most of the bugs I submit.)
> Nice!
> Do you do this transformation by hand?

No, it's all scripted, otherwise I'd have to go back to square one each
time a new revision came out.

I gave an overview here a year ago:
Steps (1) and (2) of the overview are still quite accurate about my
current work, but step (3) has changed: rather than executing the spec,
I'm focusing more on doing static analysis of it, as that's fairly
productive for finding spec-bugs.

> There have been several research projects that formalized the spec.
> I'm not saying it can't be done, I'm saying that the normative spec
> itself is not machine-readable, so you can't easily compare the
> before/after of a refactoring to check for bugs.

True, not easily. My whole pipeline from MS Word file to machine-friendly
file takes about 20 minutes (the majority of which is just waiting for
OpenOffice to load the .doc). In practice, I break the pipeline into
several steps, so that my day-to-day work only iterates on the last
couple steps, but if you wanted to check for bugs after each refactoring,
you'd need to run the whole pipeline. (On top of that, there's the fact
that each new revision introduces bugs/variations that are severe enough
that they actually cause the pipeline to break, so there's a few hours of
tweaking the pipeline to accept the new input.)

It would be nice (and not just for me) if the working version of the spec
were in a more 'transformable' format than MS Word, but that seems unlikely:

> if we were to take a formalized version of ES5 and formalized version
> of ES6 we could conceivably try to check them. But it's just not worth
> blocking the progress of the spec on these kinds of things.

Not sure why you think it would block the progress of the spec. It
wouldn't have to be AWB that does the checking.

> My feeling is, I'm fine with whatever changes Allen thinks are reasonable
> to make, but it's not worth doing more serious reworking of the spec if
> it means we either incur higher risk or block progress on formalization
> and testing/verification work.

I don't see how it could block progress on formalization or testing.

As for verification:

> I'm talking about testing or verifying equivalence between the ES5 and
> ES6 version of things that have been refactored.

Ah. Yes, that'd be tough. Mind you, it'd be tough even without the
refactoring. Is anyone working on it?


More information about the es-discuss mailing list