On Sep 10, 2014, at 6:24 PM, Boris Zbarsky wrote:
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.
On 9/11/14, 1:47 PM, Allen Wirfs-Brock wrote:
To clarify, I wasn't necessarily talking about using ES to specify Web IDL.
Rather I meant using ES as an alternative to pseudo code for specifying the
semantics of APIs defined with Web IDL interfaces.
Ah, I see.
Yeah, I'm not sure how much
For or loops are spec'ed to call the internal spec function, IteratorClose
when there is an abrupt completion in the loop body (an exception was
thrown, return and break)
The point of this was to allow cleaning up the iterator in case it holds on
to some kind of resource.
The problem is that
On Wed, Sep 10, 2014 at 7:45 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
For or loops are spec'ed to call the internal spec function, IteratorClose
when there is an abrupt completion in the loop body (an exception was
thrown, return and break)
The point of this was to allow cleaning
On 10 September 2014 16:45, Erik Arvidsson erik.arvids...@gmail.com wrote:
For or loops are spec'ed to call the internal spec function, IteratorClose
when there is an abrupt completion in the loop body (an exception was
thrown, return and break)
The point of this was to allow cleaning up the
On 10 September 2014 16:52, Mark S. Miller erig...@google.com wrote:
On Wed, Sep 10, 2014 at 7:45 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
I see two options here.
1. Add IteratorClose to all places in the spec where we use iterators.
Why was #1 rejected? I just don't remember.
I
This sounds to me like it just need to be reported as a bug There have been
previous bugs that have identified places where library methods iterated in a
manner that precluded implementing them via for-of. For example
https://bugs.ecmascript.org/show_bug.cgi?id=2083 Those bugs were all fixed.
Hi Allen, does that mean we agreed to the equivalent of Arv's #1? If so,
great!
On Wed, Sep 10, 2014 at 8:25 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
This sounds to me like it just need to be reported as a bug There have
been previous bugs that have identified places where library
On Sep 10, 2014, at 8:29 AM, Mark S. Miller wrote:
Hi Allen, does that mean we agreed to the equivalent of Arv's #1? If so,
great!
We agree at our June meeting to add the return method to generators and to
conditionally call return (if it is present) when a for-of loop terminates
before it
On 10 September 2014 17:56, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We agree at our June meeting to add the return method to generators and to
conditionally call return (if it is present) when a for-of loop terminates
before it exhausts its generator. See
On Sep 10, 2014, at 9:00 AM, Andreas Rossberg wrote:
On 10 September 2014 17:56, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We agree at our June meeting to add the return method to generators and to
conditionally call return (if it is present) when a for-of loop terminates
before it
On 9/10/14, 10:45 AM, Erik Arvidsson wrote:
1. Add IteratorClose to all places in the spec where we use iterators.
And other specs (e.g. Web IDL) that use iterators, right?
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
You want aggressive common sub-expression elimination on the specs (all
of them, as bz noted).
Is there a common helper spec-only method that can be used both inside
ES6 and by other specs?
Allen Wirfs-Brock wrote:
Yes, except that I don't think the body of those loops can actually
On Sep 10, 2014, at 10:07 AM, Boris Zbarsky wrote:
On 9/10/14, 10:45 AM, Erik Arvidsson wrote:
1. Add IteratorClose to all places in the spec where we use iterators.
And other specs (e.g. Web IDL) that use iterators, right?
Right, or come up with some other way to say: this loop behaves as
On Sep 10, 2014, at 10:24 AM, Brendan Eich wrote:
You want aggressive common sub-expression elimination on the specs (all of
them, as bz noted).
Is there a common helper spec-only method that can be used both inside ES6
and by other specs?
Not yet. Probably should be, but I have to
On 9/10/14, 1:28 PM, Allen Wirfs-Brock wrote:
Right, or come up with some other way to say: this loop behaves as if it was
implemented using for-of.
Thing is, for my Web IDL use case I don't want _quite_ the behavior of
for-of. I want something like this:
1. Let method be the result of
On Sep 10, 2014, at 10:37 AM, Boris Zbarsky wrote:
On 9/10/14, 1:28 PM, Allen Wirfs-Brock wrote:
Right, or come up with some other way to say: this loop behaves as if it
was implemented using for-of.
Thing is, for my Web IDL use case I don't want _quite_ the behavior of
for-of. I want
On 9/10/14, 1:47 PM, Allen Wirfs-Brock wrote:
1. Let method be the result of CheckIterable(V).
2. ReturnIfAbrupt(method).
3. If IsCallable(method) is false, go off and do something else,
since V is not iterable.
4. Let iter be GetIterator(V, method).
5. ReturnIfAbrupt(iter).
and then
On Sep 10, 2014, at 10:58 AM, Boris Zbarsky wrote:
On 9/10/14, 1:47 PM, Allen Wirfs-Brock wrote:
1. Let method be the result of CheckIterable(V).
2. ReturnIfAbrupt(method).
3. If IsCallable(method) is false, go off and do something else,
since V is not iterable.
4. Let iter be
On 9/10/14, 3:20 PM, Allen Wirfs-Brock wrote:
why wouldn't a self-hoster just continue with:
for (let next of iter} {
/* body */
}
I feel like I'm missing something here.
iter is an iterator, not an iterable. So I don't think this will do
the right thing, unless I'm seriously
On Sep 10, 2014, at 12:41 PM, Boris Zbarsky wrote:
On 9/10/14, 3:20 PM, Allen Wirfs-Brock wrote:
why wouldn't a self-hoster just continue with:
for (let next of iter} {
/* body */
}
I feel like I'm missing something here.
iter is an iterator, not an iterable. So I don't think
On 9/10/14, 4:11 PM, Allen Wirfs-Brock wrote:
In practice (because of for-of semantics) Iterators need to be Iterables
that return themselves as the associated iterator. All built-in
iterators in ES have this characteristic
Ah, I see. But that's observably different from just doing the loop
/ Seems to me like it's just a matter of wrapping the relevant bits (which
ones, though?
// whatever constitutes the loop body
//
// OK. That's fairly straightforward.
//
// You also will need a finally clause, if the loop body contains any explicit returns.
//
// It only does when
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boris
Zbarsky
On 9/10/14, 10:45 AM, Erik Arvidsson wrote:
1. Add IteratorClose to all places in the spec where we use iterators.
And other specs (e.g. Web IDL) that use iterators, right?
Relatedly, it would be *really*
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?
Yeah, it would.
(Not
From: Boris Zbarsky [mailto:bzbar...@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
On 9/10/14, 5:12 PM, Domenic Denicola wrote:
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.
Again, I basically copied Array.from,
On Sep 10, 2014, at 2:12 PM, Domenic Denicola wrote:
From: Boris Zbarsky [mailto:bzbar...@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
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
29 matches
Mail list logo
