Re: Writing spec algorithms in ES6?
On Thu, Jun 11, 2015 at 10:41 PM, Boris Zbarsky wrote: > On 6/11/15 4:32 PM, Dimitri Glazkov wrote: >> 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 > > I should note that the ES code there produces semantics that don't match the > IDL in this spec (or is complete nonsense, depending on how literally you > choose to read it). I think we should pick the complete nonsense interpretation as we try to be precise. If you use IDL you cannot use ES since the pipeline is ES -> IDL -> prose that operates on IDL values -> IDL -> ES. Skipping IDL altogether might be okay, but the infrastructure is not there yet, and it's way more difficult to get things right. > I would actually prefer some sort of pseudocode that is _not_ JS-looking, > just so people don't accidentally screw this up. If we had more resources I could imagine IDL 1) matching ES-syntax more and 2) define a bunch of abstract operations that specifications can use to define their features. -- https://annevankesteren.nl/
Re: Writing spec algorithms in ES6?
On 06/11/2015 11:41 PM, Boris Zbarsky wrote: I would actually prefer some sort of pseudocode that is _not_ JS-looking, just so people don't accidentally screw this up. This one please - otherwise it would be way too easy to think the algorithm would run in the context of the page. But usually the algorithms in HTML and DOM specs are quite easy to follow. The issues in readability, IMO, come from using tons of (usually spec-internal) links in algorithms, but I don't know how to solve that issue. Perhaps some tool to actually inline the relevant text from the linked place to the algorithm definition - or at least have some option to do that. -Olli
Re: Writing spec algorithms in ES6?
On Thu, Jun 11, 2015 at 1:45 PM, Ian Fette (イアンフェッティ) 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 : > >> 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< >> > >
Re: Writing spec algorithms in ES6?
On Thu, Jun 11, 2015 at 4:53 PM Domenic Denicola wrote: > Some previous discussion: [1] especiallly [2] > > In general I think this is a reasonable thing, but it requires a decent > bit more infrastructure to do things “safely”. For example, consider the > definition [3]. It's generic in its arguments, which I think is nice (but > does not fit with Web IDL---whatever). However, it's susceptible to author > code overriding Array.prototype.join. Similarly, [4] relies upon the > author-modifiable Math.max and Math.min, not to mention the > author-modifiable Math binding. > Yep. The correct way to use these is to normatively reference the Well-Known Intrinsic Objects Table[0] in ES2015, and cite any "extensions". This is how Ecma 402 and the new SIMD spec ensure object integrity when referring to built-ins. Rick [0] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-well-known-intrinsic-objects
Re: Writing spec algorithms in ES6?
I've seen this in some specs, and I found the JS code quite difficult to understand. There's so much subtle behavior you can do, and it's easy to be "too fancy." In the example in the color spec, why does undefined become 0 but not null? Also the properties are actually doubles so there's missing type coercion in that pseudo code I think. On Thu, Jun 11, 2015 at 1:50 PM, Erik Arvidsson wrote: > Dare I say ecma-speak? > > (Maybe I got stockholm-syndrome?) > > On Thu, Jun 11, 2015 at 4:47 PM, Adam Klein wrote: > > On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov > > wrote: > >> > >> 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? > > > > > > I love the idea of specifying algorithms in something other than English. > > But I'm afraid that ECMAScript is not a good language for this purpose, > for > > the same reasons Boris cites in his response (which arrived as I was > typing > > this). > > > > - Adam > > > > -- > erik > >
Re: Writing spec algorithms in ES6?
On Thu, Jun 11, 2015 at 1:41 PM, Boris Zbarsky wrote: > On 6/11/15 4:32 PM, Dimitri Glazkov wrote: >> 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 > > I should note that the ES code there produces semantics that don't match the > IDL in this spec (or is complete nonsense, depending on how literally you > choose to read it). Yes, the code currently there is... loose. There's a lot of problems trying to map IDL directly into ES without a lot of boilerplate. > So there are basically at least two problems here: > > 1) You have to clearly delineate when you're working with JS values and > when you're working with IDL values, to the extent that these are not the > same thing. > > 2) You have to clearly delineate which bits of JS run in the page global > and which bits run in some other clean global and which bits run in the page > global but have access to some clean intrinsics somehow. > > I would actually prefer some sort of pseudocode that is _not_ JS-looking, > just so people don't accidentally screw this up. I actually rather like using JS code for these; it's familiar and easy to read. But yeah, Domenic outlines some of the things we'd have to change before this was actually useful. I wrote Color the way I did because writing math in prose is *incredibly* awkward, but writing it in ES-ese is *even more incredibly awkward*. So for now, I opted for the insufficient third alternative of "JS, if we handwave and pretend all the obvious problems don't occur". ~TJ
Re: Writing spec algorithms in ES6?
Dare I say ecma-speak? (Maybe I got stockholm-syndrome?) On Thu, Jun 11, 2015 at 4:47 PM, Adam Klein wrote: > On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov > wrote: >> >> 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? > > > I love the idea of specifying algorithms in something other than English. > But I'm afraid that ECMAScript is not a good language for this purpose, for > the same reasons Boris cites in his response (which arrived as I was typing > this). > > - Adam -- erik
RE: Writing spec algorithms in ES6?
Some previous discussion: [1] especiallly [2] In general I think this is a reasonable thing, but it requires a decent bit more infrastructure to do things “safely”. For example, consider the definition [3]. It's generic in its arguments, which I think is nice (but does not fit with Web IDL---whatever). However, it's susceptible to author code overriding Array.prototype.join. Similarly, [4] relies upon the author-modifiable Math.max and Math.min, not to mention the author-modifiable Math binding. I go into these issues in a bit more detail in [5], although that's from an implementation perspective. Regardless, it at least opens with another good example. If we wanted to make this feasible---and I think that would be a good thing---I think at a minimum we'd need: - "JS bindings" for all the ES abstract operations, so you could do e.g. max(...) or DefinePropertyOrThrow(...) instead of Math.max(...) and Object.defineProperty(...) - Some way of expressing private state in ES. (Maybe WeakMaps are sufficient, semantically, but syntactically they are awkward.) - Some kind of Record type, as well as some kind of List type, corresponding to those in the ES spec. Trying to use just objects or arrays will fail in the face of modifications to Object.prototype and Array.prototype. (Boris goes over this in [2]) It's a decent bit of work... [1]: https://esdiscuss.org/topic/for-of-loops-iteratorclose-and-the-rest-of-the-iterations-in-the-spec [2]: https://esdiscuss.org/topic/for-of-loops-iteratorclose-and-the-rest-of-the-iterations-in-the-spec#content-26 [3]: http://dev.w3.org/csswg/css-color/#dom-rgbcolor-stringifiers [4]: http://dev.w3.org/csswg/css-color/#dom-hslcolor-hslcolorrgb [5]: https://docs.google.com/document/d/1AT5-T0aHGp7Lt29vPWFr2-qG8r3l9CByyvKwEuA8Ec0/edit#heading=h.9yixony1a18r
Re: Writing spec algorithms in ES6?
On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov wrote: > 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? > I love the idea of specifying algorithms in something other than English. But I'm afraid that ECMAScript is not a good language for this purpose, for the same reasons Boris cites in his response (which arrived as I was typing this). - Adam
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 : > 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< >
Re: Writing spec algorithms in ES6?
On 6/11/15 4:32 PM, Dimitri Glazkov wrote: 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 I should note that the ES code there produces semantics that don't match the IDL in this spec (or is complete nonsense, depending on how literally you choose to read it). So there are basically at least two problems here: 1) You have to clearly delineate when you're working with JS values and when you're working with IDL values, to the extent that these are not the same thing. 2) You have to clearly delineate which bits of JS run in the page global and which bits run in some other clean global and which bits run in the page global but have access to some clean intrinsics somehow. I would actually prefer some sort of pseudocode that is _not_ JS-looking, just so people don't accidentally screw this up. -Boris
