Re: Writing spec algorithms in ES6?

On Thu, Jun 11, 2015 at 1:45 PM, Ian Fette (イアンフェッティ) <ifette@google.com>
wrote:

> To be honest this always drove me nuts when we were trying to do
> WebSockets. Having code is great for conformance tests, but a spec IMO
> should do a good job of setting out preconditions, postconditions,
> performance guarantees (e.g. STL algorithms specifying runtime complexity)
> and error handling. When you just list code for what the function means,
> that leaves alternate implementations rather ambiguous as to what is a spec
> violation and what is not. For instance, stringifiers - what if an
> implementation rounds things to some finite precision rather than
> multiplying by 100 and spewing out some arbitrary length percentage? is
> this correct? Or do you have to just use the code in the spec as given? And
> if you use the code in the spec as given and everyone implements in exactly
> the same way, why not just publish a library for it and say to heck with
> the spec?
>

IMHO, the imperative/algorithmic style is necessary to get you to the point
where the guts of behavior can be completely described using
preconditions/postconditions and abstract concepts, which is where the meat
of the specification really should be. When we haven't been that precise,
we have observable implementation differences. (Um, yeah, so I'd say that
stringifier spec is imprecise and we'll have compat issues)

I just did a rework of the IDB "v2" editor's draft and probably 90% of the
spec is basically an additional layer of "bindings" between
WebIDL/ECMAScript and the the core concepts of the spec. That 90% was
previously written as blocks of prose rather than imperative algorithms and
behavior does differ among implementations. Fortunately, that mostly
applies to edge cases (bad inputs, getters/setters). Maybe it's just IDB,
but the remaining 10%of the spec is where all the fun
implementation-specific optimizations happen and is 90% of the actual code,
it's just short in the spec because it can be described in abstract terms.


> 2015-06-11 13:32 GMT-07:00 Dimitri Glazkov <dglazkov@google.com>:
>
>> Folks,
>>
>> Many specs nowadays opt for a more imperative method of expressing
>> normative requirements, and using algorithms. For example, both HTML and
>> DOM spec do the "run following steps" list that looks a lot like
>> pseudocode, and the Web components specs use their own flavor of
>> prose-pseudo-code.
>>
>> I wonder if it would be good the pseudo-code would actually be ES6, with
>> comments where needed?
>>
>> I noticed that the CSS Color Module Level 4 actually does this, and it
>> seems pretty nice:
>> http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor
>>
>> WDYT?
>>
>> :DG<
>>
>
>