domenic at domenicdenicola.com (2013-12-10T01:37:27.441Z)
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*?
> ... 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.
> 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.
[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.
Furthermore, I just think people will find it surprising that from/map
don't operate as analogously as possible (I certainly did).
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*? > ... 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. > 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. [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. Furthermore, I just think people will find it surprising that from/map don't operate as analogously as possible (I certainly did). Niko