'void' as a value

Brendan Eich brendan at mozilla.com
Sun Sep 8 14:56:42 PDT 2013


> Andrew Fedoniouk <mailto:news at terrainformatica.com>
> September 8, 2013 2:11 PM
>
>>> ...
>>>
>>> Internal implementation of for..in is calling the function in each
>>> iteration
>>> and stops when the function will return 'void'.
>> Assuming you mean for-of, the problems for any "new undefined-like sentinel"
>> remain:
>>
>> * It will be too easily returned by accident, especially given how it is
>> hard to distinguish from undefined.
>
> I do not understand the problem to be honest. Are you saying that
> it is hard to distinguish these two cases:
>
>    return something;
>    // and
>    return;
>
> ?

A reader can distinguish those, although return undefined; is less easy 
to spot at a glance. And delegation, meaning return bar(); where bar 
returns undefined, is in general beyond static analysis. So, yes!

The situation is worse when you consider the caller, not the callee (the 
iterator-consumer, not the iterator implementation). People *will* mix 
up undefined and void, Murphy was an optimist.

>> * It may end up in collections being iterated over, causing premature
>> termination.
>
> I think you've missed my point. 'void' IS 'undefined' by any means
> except of slightly
> different internal representation. It is like 'undefined' value has
> special flag .isVoid that
> is not exposed outside.
>
> While assigning that undefined/isVoid value to any variable or field
> the isVoid gets
> cleared - in other words you cannot store void value anywhere.

This fixes only part of the problem (see delegation point above). Worse, 
it requires a write barrier to censor void via undefined. That is going 
to lose any implementors who aren't sold otherwise.

> So collections or variables simply cannot contain 'void' values. void is void.

Collection in space is stream in time, the delegation problem remains. 
But you are right, I should have added the write barrier to the 
bullet-list of problems!

>> Any in-band value is a problem by the latter point. Thus the previous
>> Pythonic out-of-band StopIteration exception, or the current ES6 wrapping of
>> iteration protocol step results in {value, done} structure to avoid
>> overloading the returned value and creating a pigeon hole problem.
>
> {value, done}  creates another problem - heap pollution, this:
>
> var counter = 0;
> for( var n of Range(0,10) )
>    ++counter;
>
> should not cause heap allocations.

I quite agree, and proposed StopIteration (in general, a class, per 
PEP380) for years. But this heap allocation is relatively 
straightforward to avoid in modern JITs, compared to other optimizations 
already done for JS. When for-of drivers the iteration, there's no need 
for the allocation, which is typically done in a return expression:

function Range(start, end) {
   let i = start;
   return {
     next: function () {
       if (i >= end) return {done: true};
       return {value: i++, done: false};
     }
   };
}

Generator functions make optimization even easier, since the returned 
object shape is guaranteed:

function Range(start, end) {
   for (let i = start; i < end; i++)
     yield i;
}

> In case of protocol you've described
> {value, done} object gets allocated. And I suspect it is so on each iteration.

Not observably when for-of creates and drives the iteration protocol and 
the iterator does not pass or stash a reference to the returned {value, 
done} object anywhere else.

This optimization possibility is a crucial part of the design. Were it 
not so, I suspect we would still be using an OOB exception approach.
>
> ...
>
> "ĄBasta!"
>
> Creo en tu palabra.

Gracias.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130908/004b2c40/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130908/004b2c40/attachment.jpg>


More information about the es-discuss mailing list