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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
