Yes. Sorry, it was composed by Brent - not sure why I thought it was Erica - 
that is why I couldn't find it. Thanks!

> On Jun 28, 2016, at 9:11 AM, David Rönnqvist <[email protected]> 
> wrote:
> 
> Is this (below) the list you were referring to? (copied from: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/021301.html
>  
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/021301.html>
>  )
> 
> - David 
> 
> ——————————————————————————————
> 
> `map`, `filter`, and `reduce` are *the* higher-order functions. Almost 
> anything with any kind of block/lambda/closure feature supports them (I'm 
> giving the side-eye to Foundation here), and all three names are backed by 
> *very* strong conventions:
> 
> * `map` is by far the strongest. It is universally supported among languages 
> with higher-order collection operations, and is almost always called `map`. 
> In Wikipedia's list of 32 languages with a `map` 
> <https://en.wikipedia.org/wiki/Map_(higher-order_function)#Language_comparison
>  
> <https://en.wikipedia.org/wiki/Map_(higher-order_function)#Language_comparison>>,
>  we find (grouping together similar names like `map` and `maplist`, and 
> double-counting languages with several aliases):
> 
>       Map: 19
>       Collect: 3
>       Apply: 3
>       Special syntax: 2
>       Select: 1 (C#, which uses it in the SQL-inspired LINQ)
>       Transform: 1 (C++, which uses a bizarre signature involving an out 
> parameter)
>       ForEach: 1 (XPath)
> 
> * `filter` is supported nearly as widely as `map`, and the name `filter` is 
> used nearly as consistently as `map`. Wikipedia lists 27 languages supporting 
> a `filter`-style function, and `filter` is by far the most common choice, 
> arguably favored even more consistently than `map` 
> <https://en.wikipedia.org/wiki/Filter_(higher-order_function) 
> <https://en.wikipedia.org/wiki/Filter_(higher-order_function)>>:
> 
>       Filter: 17
>       Select: 4
>       Special syntax: 3
>       FilteredArrayUsingPredicate: 1 (Foundation, doesn't actually take a 
> closure)
>       Where: 1 (C#, in LINQ)
>       CopyIf: 1 (C++, bizarre signature)
>       FindAll: 1
>       Grep: 1
>       RemoveIfNot: 1
> 
> * `reduce` is extremely popular among functional languages because it's a 
> primitive list-handling operation, although it's a little less common among 
> mainstream languages than the other two. It *does* actually have an alternate 
> name, `fold`, which is nearly as common as `reduce`. However, languages using 
> `fold` are usually those which support both leftward- and rightward-reducing 
> versions of the operation, whereas languages using `reduce` usually don't. 
> Swift falls into the second camp. From Wikipedia's 39-language list 
> <https://en.wikipedia.org/wiki/Fold_(higher-order_function) 
> <https://en.wikipedia.org/wiki/Fold_(higher-order_function)>>:
> 
>       Reduce: 20      (with both left and right: 4)
>       Fold: 18        (with both left and right: 12)
>       Inject: 3
>       Special syntax: 3
>       Aggregate: 1 (C#, in LINQ)
>       Accumulate: 1 (C++, bizarre signature)
>       Partition: 1
>       ToIterator: 1
> 
> 
>> On 28 Jun 2016, at 07:31, Charlie Monroe via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>> Erica had a nice list of various term-of-art usages among languages - it 
>> included filter, map, etc. - I just can't seem to find it anywhere. This 
>> nicely showed that there is only a few languages that name things 
>> differently, mostly C# and C++.
>> 
>> "filter" is nowadays quite a universal word that is in many languages - and 
>> I'm talking both about programming and a natural language. And I don't think 
>> that it goes against what one might be expecting - when you open a filter in 
>> the UI, you don't tick things that you don't want to see, but items that you 
>> *do* want to see.
>> 
>> I don't think that changing those names will add any additional value to the 
>> Swift language. I've personally had more issues with the naming of flatMap - 
>> it could have been called filterMap to stay in line of filtering by 
>> returning nil (flattening an array is in my head associated with flattening 
>> of an array of arrays). But it's a term of art and I got my head around it. 
>> 
>>> On Jun 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution 
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>> Under consideration is the resolution that  "some terms of art while 
>>> appropriate to many FP languages, may be better served by using Swift 
>>> names."
>>> 
>>> Consider, for example, `filter(_:)`. Sean Heber writes,
>>> 
>>>> Just tossing my vote in the hat for renaming .filter() to something like 
>>>> .select() since that better matches what it does, IMO. “Filter” is almost 
>>>> like the opposite word from what it should be since the closure returning 
>>>> true is what decides what is included in the results, not what is filtered 
>>>> *from* the results. I mean, yeah, I can kind of understand the logic 
>>>> either way, but it’s always been one of those strange mental gymnastics 
>>>> things."
>>> 
>>> 
>>> When asked "Shouldn't there be a term of art exemption for `filter(_:)`. 
>>> Otherwise why not use `select(where:)`," Dave Abrahams replies:
>>> 
>>>> Because `where(...)` is better.
>>> 
>>> 
>>> Have at it.
>>> 
>>> -- E
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to