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 IteratorStep my way through "iter".
>
> So, try expressing this in JS. That's what a JS help-hosting compliant implementation is going to have to do.

Sure.

   var method = V[Symbol.iterator];
   if (typeof method != "function") {
     // Not iterable; do something else
   }
   var iter = method.call(iter);

and then go through calling .next() and so on.

Now in this self-hosted case, how do I express IteratorClose?  Seems to 
me like it's just a matter of wrapping the relevant bits (which ones, 
though?) in a try/catch and doing this in the catch clause:

   catch (e) {
     if ("return" in iter) {
       iter.return();
     }
     throw e;
   }

That ought to match the semantics of IteratorClose, yes?

-Boris

On 9/10/14, 1:47 PM, Allen Wirfs-Brock wrote:

> So, try expressing this in JS. That's what a JS help-hosting compliant implementation is going to have to do.

Sure.

```js
var method = V[Symbol.iterator];
if (typeof method != "function") {
  // Not iterable; do something else
}
var iter = method.call(iter);
```

and then go through calling .next() and so on.

Now in this self-hosted case, how do I express IteratorClose?  Seems to 
me like it's just a matter of wrapping the relevant bits (which ones, 
though?) in a try/catch and doing this in the catch clause:

```js
catch (e) {
  if ("return" in iter) {
    iter.return();
  }
  throw e;
}
```

That ought to match the semantics of IteratorClose, yes?