On Jun 28, 2016, at 9:11 AM, David Rönnqvist <firstname.lastname@example.org> 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 )
`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):
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)>>:
Special syntax: 3
FilteredArrayUsingPredicate: 1 (Foundation, doesn't actually take a closure)
Where: 1 (C#, in LINQ)
CopyIf: 1 (C++, bizarre signature)
* `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)
Special syntax: 3
Aggregate: 1 (C#, in LINQ)
Accumulate: 1 (C++, bizarre signature)
On 28 Jun 2016, at 07:31, Charlie Monroe via swift-evolution <email@example.com <mailto:firstname.lastname@example.org>> 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@example.com <mailto:firstname.lastname@example.org>> 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.
swift-evolution mailing list
swift-evolution mailing list