for-of loops, IteratorClose and the rest of the iterations in the spec

Boris Zbarsky bzbarsky at mit.edu
Wed Sep 10 18:24:45 PDT 2014


On 9/10/14, 5:48 PM, Allen Wirfs-Brock wrote:
> 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".

There are a few issues with using ES for specifying Web IDL.  It's 
possible that these can be overcome, of course.

First, ES doesn't actually have some of the data types involved.  There 
is no record type that would correspond to an IDL dictionary, for 
example.  You could use objects, or Maps to represent those, but would 
need to make it very clear that those are not using the page-modifiable 
prototypes, while continuing to operate in the page Realm in some sense.

Second, and related to the first item, Web IDL needs to operate on 
property descriptors, because it needs to define the behavior of some 
internal operations like [[Get]] and [[GetOwnProperty]].  This comes 
back to not having records; operations on descriptor objects are not the 
same thing, again unless you assume clean prototypes somehow.

Third, a number of the desired operations (ToUint32, ToInt32, ToNumber, 
ToBoolean, ToString, ToObject, Type) are somewhere betwee "a pain" and 
"starts to look like an obfuscated programming contest" when you try to 
do them in ES proper.  So whatever specification formalism we use needs 
to be able to reference these directly.  A Spec-ES could do that, of course.

Fourth, any algorithm that uses lists would need to make it clear that 
the lists use the magic clean Array.prototype while arrays in the same 
algorithm might use the normal page-modifiable prototype.

Fifth, Web IDL needs to be able to call [[DefineOwnProperty]] and the 
like.  This can be done via Object.defineProperty as long as you once 
again make it very clear which operations are using a clean Object and 
which are not.

So I guess my main issue here is the same one that self-hosted builtin 
implementations have in V8 and SpiderMonkey: you have to be _really_ 
careful to distinguish between your usage of clean built-in stuff and 
page-visible stuff.  The result can be fairly taxing to write, read, 
reason about, and modify.  It's doable, but I'm not sure whether the end 
result would be better than what we have now.  :(

> In the long run, we could probably also do this for many of the ES built-ins

This would be a good exercise for dealing with some of the above sorts 
of problems, yes....

> And I really hope that most APIs spec'ed using WebIDL are designed to be implementable  using ES.

Most APIs I've seen people adding recently really aren't, because they 
seem to be about low-level hardware access and whatnot.  For what it's 
worth.

-Boris


More information about the es-discuss mailing list