On Dec 6, 2013, at 1:00 PM, Niko Matsakis wrote:

> On Fri, Dec 06, 2013 at 09:08:09AM -0800, Allen Wirfs-Brock wrote:
>> 1) For the map method, the source and destination collection are the
>> same object ...
> 
> How are the source and destination collection the same in the case of
> map()? Perhaps you meant that they are the same *type of collection*?

No, I just wasn't fully awake yet...

> 
>> ... the actual source index (if there even is one) may be different from the destination index ...
> 
> This is true, but I'm not sure how important it is. Just define the
> index to be the number of items traversed thus far. If users move
> `from` to other types for which a numeric index is inappropriate
> (e.g., `set`), so be it.

But aren't we now back to your parallelism problem.  It would seem that the only index/count like value that is order and Iterator protocol  independent is the destination index. 

> 
>> 2) For the from method, the source collection is usually accessed using an Iterator.  That itself may be problematic from a parallel perspective that you need to consider.
> 
> Yes, a parallel version of from can only be used with collections that
> support indexing.

Note as currently specified, the from methods prefer Iterator protocol over indexing for when presented with a source collection that supports both.  

> 
> [As a side note, we offer a "parallel build" operation that simply
> iterates over an iteration space without reference to any
> collection. It is possible to rewrite both from and map in terms of
> build, at least for any indexable collection. So in some sense this
> change is not *necessary* for expressiveness, even in the
> parallel setting, but I still think it's a good idea.]
> 
>> ...perhaps we should think about whether it is a good idea to add
>> more such capability leaks...
> 
> It's easy enough to plug capability leaks like so:
> 
>    Int32Array.from(e => insecureClosure(e))
> 
> Given that the cat is out of the bag thanks to map, this doesn't seem
> like it's even a footgun.
> 
>> Do you have any real use cases where knowledge of the destination collection and index is actually needed. 
> 
> I don't personally think the *collection* argument is especially
> useful. You can always capture it in the closure if you like.
> I only included the collection argument for consistency with map.
> 
> The *index* however is clearly useful. Most every generic iteration
> facility I've seen includes an adapter like Python's enumerate() or
> Scala's zipWithIndices() precisely because having access to the index
> is a handy thing. As examples, consider a function that wants to
> access the neighbors of the current element.

Yes, but in the interator source scenario indexed access to the source collection may not be available.

> 
> Furthermore, I just think people will find it surprising that from/map
> don't operate as analogously as possible (I certainly did).
> 

Does the surprise then lead you to deeper understanding of essential differences?

Essentially what we are discussing is whether or not they actually already are as close as possible,

Allen

On Dec 6, 2013, at 1:00 PM, Niko Matsakis wrote:

> How are the source and destination collection the same in the case of
> map()? Perhaps you meant that they are the same *type of collection*?

No, I just wasn't fully awake yet...

> This is true, but I'm not sure how important it is. Just define the
> index to be the number of items traversed thus far. If users move
> `from` to other types for which a numeric index is inappropriate
> (e.g., `set`), so be it.

But aren't we now back to your parallelism problem.  It would seem that the only index/count like value that is order and Iterator protocol  independent is the destination index. 

> Yes, a parallel version of from can only be used with collections that
> support indexing.

Note as currently specified, the from methods prefer Iterator protocol over indexing for when presented with a source collection that supports both.  

> I don't personally think the *collection* argument is especially
> useful. You can always capture it in the closure if you like.
> I only included the collection argument for consistency with map.
> 
> The *index* however is clearly useful. Most every generic iteration
> facility I've seen includes an adapter like Python's enumerate() or
> Scala's zipWithIndices() precisely because having access to the index
> is a handy thing. As examples, consider a function that wants to
> access the neighbors of the current element.

Yes, but in the interator source scenario indexed access to the source collection may not be available.

> Furthermore, I just think people will find it surprising that from/map
> don't operate as analogously as possible (I certainly did).

Does the surprise then lead you to deeper understanding of essential differences?

Essentially what we are discussing is whether or not they actually already are as close as possible,