Is this (below) the list you were referring to? (copied from: 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]> 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 > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
