Re: Writing spec algorithms in ES6?

2015-06-12 Thread Anne van Kesteren
On Thu, Jun 11, 2015 at 10:41 PM, Boris Zbarsky bzbar...@mit.edu 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?

2015-06-11 Thread Erik Arvidsson
Dare I say ecma-speak?

(Maybe I got stockholm-syndrome?)

On Thu, Jun 11, 2015 at 4:47 PM, Adam Klein ad...@chromium.org wrote:
 On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov dglaz...@google.com
 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?

2015-06-11 Thread Adam Klein
On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov dglaz...@google.com
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?

2015-06-11 Thread Domenic Denicola
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?

2015-06-11 Thread Elliott Sprehn
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 a...@google.com wrote:

 Dare I say ecma-speak?

 (Maybe I got stockholm-syndrome?)

 On Thu, Jun 11, 2015 at 4:47 PM, Adam Klein ad...@chromium.org wrote:
  On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov dglaz...@google.com
  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?

2015-06-11 Thread Joshua Bell
On Thu, Jun 11, 2015 at 1:45 PM, Ian Fette (イアンフェッティ) ife...@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 dglaz...@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





Re: Writing spec algorithms in ES6?

2015-06-11 Thread Boris Zbarsky

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



Re: Writing spec algorithms in ES6?

2015-06-11 Thread イアンフェッティ
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 dglaz...@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



Re: Writing spec algorithms in ES6?

2015-06-11 Thread Rick Waldron
On Thu, Jun 11, 2015 at 4:53 PM Domenic Denicola d...@domenic.me 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?

2015-06-11 Thread Tab Atkins Jr.
On Thu, Jun 11, 2015 at 1:41 PM, Boris Zbarsky bzbar...@mit.edu 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?

2015-06-11 Thread Olli Pettay

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