Re: Writing spec algorithms in ES6?

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?

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<
>