for-of loops, IteratorClose and the rest of the iterations in the spec
allen at wirfs-brock.com
Wed Sep 10 14:48:44 PDT 2014
On Sep 10, 2014, at 2:12 PM, Domenic Denicola wrote:
> From: Boris Zbarsky [mailto:bzbarsky at mit.edu]
>> On 9/10/14, 4:57 PM, Domenic Denicola wrote:
>>> Relatedly, it would be *really* nice to have a spec-level for-of, both for ES and for web specs.
>> You mean so people don't have to write things like http://heycam.github.io/webidl/#add-map-elements-from-iterable by hand?
> Sorry, my mail client didn't see the threading on this, so after getting through the rest of my emails I realize that's what much of the rest of the conversation was about. But yes, exactly :)
> For https://github.com/heycam/webidl/pull/18, I think it would be ideal to use exact for-of if possible, perhaps after an initial discrimination, instead of manually doing all those things to the iterable.
> So yeah, ideally we should define something so that specs can say
>> 1. For <var>x</var> of <var>someIterable</var>,
>> 1. Use <var>x</var> in some way.
> Perhaps WebIDL is the best place to do that for now.
>>> (Not to mention a spec-level try/catch, but that's another story...)
>> Abrupt completions sort of give you that in ES. Or did you mean so you don't have to sprinkle ReturnIfAbrupt() everywhere?
> Right. ReturnIfAbrupt always felt to me like an overreaction to the problem of underspecified exception handling behavior. Something like: "Try: (... substeps ...) Catch _e_: ( ... substeps ... )" would be quite nice, at times.
So you want a language with structured control constructs. We actually have such a language - its called ECMAScript :-)
But, really the ES spec (at least chapters 6-15) has to operate using primitive abstractions like abrupt completions, etc. because it is defining the execution model of the higher level structured controls constructs (including closures, etc.)
But I don't see any reason why most of what is defined in WebIDL has to be specified using those low level control abstractions. Why not just us ES as the specification language for most things in the WebIDL world? Or if not full ES, a simplified form "Spec-ES".
In the long run, we could probably also do this for many of the ES built-ins but there is no pressing need do such a rewrite at this time. But I don't see why new WebIDL level specs. would want to burden themselves with such a low level notation. And I really hope that most APIs spec'ed using WebIDL are designed to be implementable using ES.
More information about the es-discuss