'void' as a value

Axel Rauschmayer axel at rauschma.de
Sun Sep 8 15:34:54 PDT 2013


Generators can also return values, not only yield them: That way, a generator function can call another one via `yield*` and receive a result (the value returned by the latter generator function [1]). That’s why a sentinel value is not enough, you need to be able to indicate that the iterator is done and to return a value at the same time.

As for allocating too many objects: To iterate, you already need to create an iterator object. If I’m not mistaken, the next() method could return `this` and the iterator itself could have the properties `value` and `done`.


[1] http://www.2ality.com/2013/06/iterators-generators.html


On Sep 8, 2013, at 23:11 , Andrew Fedoniouk <news at terrainformatica.com> wrote:

> On Sun, Sep 8, 2013 at 12:39 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> Lately people post overlong proposals that do not define the proposed
>> primitives first. Also errors in the sketching don't help credibility.
>> 
>>> Andrew Fedoniouk <mailto:news at terrainformatica.com>
>>> September 8, 2013 11:24 AM
>>> 
>>> Consider this Range implementation:
>>> 
>>> function Range(low, high){
>>> var index = low;
>>> return function() { if( index < high ) return index++; }
>>> }
>>> 
>>> and its use:
>>> 
>>> for(var i in Range(0,10) )
>> 
>> 
>> You must mean for (var i of Range(0, 10)) here, because for-in cannot be
>> changed to iterate without breaking backward compatibility.
> 
> Correct, "for..of"  is the right construct for that.
> 
>> 
>>> ...
>>> 
>>> 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;
> 
> ?
> 
>> 
>> * 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.
> 
> So collections or variables simply cannot contain 'void' values. void is void.
> 
>> 
>> 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. In case of protocol you've described
> {value, done} object gets allocated. And I suspect it is so on each iteration.
> 
> ...
> 
> "ĄBasta!"
> 
> Creo en tu palabra.
> 
> -- 
> Andrew Fedoniouk.
> 
> http://terrainformatica.com
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130909/cb9d57f3/attachment-0001.html>


More information about the es-discuss mailing list