On Dec 6, 2013, at 2:28 AM, Niko Matsakis wrote:

> Let me expand on this e-mail a bit more. I am motivated here by our
> work on the data parallelism API [1]. As I mentioned in the Boston
> meeting, we have been adding alternatives to methods like `from()`
> that attempt parallel execution (e.g., `fromPar()`). In general, we
> aim for these methods to be as compatible with the existing signatures
> as possible.
> 
> In the case of `from()`, in a sequential world, one might work around
> the lack of an index argument by writing code like:
> 
>    var counter = 0;
>    var f1 = Int32Array.from(f, e => e + counter++)
> 
> rather than
> 
>    var f1 = Int32Array.from(f, (e, i) => e + i)
> 
> However, this would not work in a parallel setting, since `counter`
> would be shared mutable state. Parallel APIs require the second
> approach. I would argue the second approach is preferable anyhow, as
> it is a more declarative style.
> 
> I realize that the spec includes this comment about reusability:
> 
> "NOTE The from function is an intentionally generic factory method; it
> does not require that its this value be the Array
> constructor. Therefore it can be transferred to or inherited by any
> other constructors that may be called with a single numeric argument."
> 
> There is no particular reason, though, that `from()` cannot include an
> index and collection argument, even if the source value is not an
> array. In that event, `index` simply represents the number of items
> that have been iterated over thus far.

Note that from is different from map in two important ways

1)  For the map method, the source and destination collection are the same object so the collection argument to the closure parameter identifiers both the source and destination object and the sole index parameter identifies both the source and destination index.  With the from method, the source and destination objects may have distinct identity and (because of the use of iterators) the actual source index (if there even is one) may be different from the destination index.  You might equally argue that the signature of the closure should be (value, destCollection, destIndex, srcCollection, srcIndex(,

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. 

Finally, I can imagine that the security conscience might view the implicit passing of the target collection to the closure as a capability leak.  Imagine a closure provided by an untrusted source.  Passing the target collection allows them to capture a reference to the collection that they might later misuse.  I know that the existing Array methods already have this characteristic, but perhaps we should think about whether it is a good idea to add more such capability leaks. 

I'm actually not unsympathetic to this request, but I think we should examine some of these design issues before committing to any changes.

Do you have any real use cases where knowledge of the destination collection and index is actually needed. 

Allen

Note that from is different from map in two important ways

1.  For the map method, the source and destination collection are the same object so the collection argument to the closure parameter identifiers both the source and destination object and the sole index parameter identifies both the source and destination index.  With the from method, the source and destination objects may have distinct identity and (because of the use of iterators) the actual source index (if there even is one) may be different from the destination index.  You might equally argue that the signature of the closure should be (value, destCollection, destIndex, srcCollection, srcIndex(,

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. 

Finally, I can imagine that the security conscience might view the implicit passing of the target collection to the closure as a capability leak.  Imagine a closure provided by an untrusted source.  Passing the target collection allows them to capture a reference to the collection that they might later misuse.  I know that the existing Array methods already have this characteristic, but perhaps we should think about whether it is a good idea to add more such capability leaks. 

I'm actually not unsympathetic to this request, but I think we should examine some of these design issues before committing to any changes.

Do you have any real use cases where knowledge of the destination collection and index is actually needed.