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