On 17 Jun 2016, at 8:21 AM, Brent Royal-Gordon via swift-evolution
<[email protected]> wrote:
map => mapped
flatMap => flatMapped
filter => filtered
reduce => reduced
You posted before I finished responding to this on the other thread, so I guess
I'll do it here.
You're right that renaming these operations wouldn't be terrible. But I think
they're easily distinguishable from things like `dropFirst`, and
distinguishable in a way that tilts rather strongly towards leaving these as-is.
`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>,
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)>:
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)>:
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
(Note that, although I *would* have counted the -ed or -ing forms of these
names with the originals, I don't believe I saw any.)
Great research. Thanks for doing this.
Another illustration of the strength of these names: Google named a distributed
computing project MapReduce, and everyone basically understood what it meant.
If `map`, `filter`, and `reduce` are not covered by the term-of-art rule, we
might as well rename it to the sin()-and-Int rule, because I don't know what
else it would cover. There is remarkable consistency in the naming of these
operations across dozens of languages.
(Incidentally, I think if we *do* decide to rename the main higher-order list
APIs, they would be better named as `mapping(to:)`, `flatMapping(to:)`,
`filtering(by:)`, and `reducing(from:with:)`. Unlike `sorted`, the parameters
are mandatory and deeply necessary to understand what the call does, so they
deserve grammatical labels. Grammatical labels usually imply -ing form, not -ed
form. If we want to address Dave's complaint about the ambiguity of `filter`,
we might rename that to `selecting(where:)`, which is crystal clear about
whether it keeps the true elements or the false ones.)
It would seem strange in one way to get rid of such strong terms of art (and
also since they are nice and short, they are easy to glance at), but it also
seems very inconsistent to keep them. These are methods that will be used by
new programmers to Swift, so is it better to keep the existing terms or to
modify them?
Say my type has a method filtered(with: Author), is it then strange that I am
changing tense within the method’s implementation?
filtered(with author: Author) -> [Item] {
return items.filter{ $0.author == author }
}
Would it not make more sense to write?
filtered(with author: Author) -> [Item] {
return items.filtered(where: { $0.author == author })
}
dropFirst => droppingFirst
dropLast => droppingLast
Here, however, I think you're being under-ambitious.
* Even with a nonmutating suffix, `dropping` carries such a strong connotation
of deletion that I think it's a poor choice. I would prefer `skipping`, which
is much more clearly an operation that doesn't change anything (and finds
precedent in other languages—`skip*` functions are a common alternative name
for `drop*` functions.)
+1 to skipping
* The `First` and `Last` suffixes are inappropriate for the versions of this
function which take an argument. These are inverse operations to `prefix(_:)`
and `suffix(_:)`, and should be named accordingly.
* `prefix(upTo:)`, `prefix(through:)`, and `suffix(from:)` are sort of strange,
because they're tied deeply into indices and aren't closely related to the
other prefix/suffix methods. I would at least seriously consider renaming these
to `upTo(_:)`, `through(_:)`, and `from(_:)`—or perhaps even reimagine these
entirely as subscripts `[upTo:]`, `[through:]`, and `[from:]`.
I really like the subscript idea. Named subscripts are not used nearly enough
as they could. This gives these similar index-related operations a common home,
and I believe would work well with autocomplete after typing a `[`.
I could even imagine a `[filtering:]` / `[where:]` / `[passing:]` instead of
`filtered()`, but can imagine it might be unpopular.
This is the area where the term-of-art argument is weaker, the API is more
inconsistent and difficult to understand, and the methods are more rarely seen
and so more important to be understandable without remembering them. All of
these factors combine to make the gains from rationalizing them greater.
`map`, `flatMap`, `filter`, and `reduce` are in some ways the "sexy" targets: We use them
all over the place, and changing them would "fix" more lines of code. But these calls are
so common, and so heavily precedented, that few users will be confused by them—they've probably
seen them before Swift, and even if they haven't, they'll see them enough to keep their meanings
fresh in their minds. It is the dimmer, less loved corners of the standard library which we ought
to focus on, because they stand to benefit much more from following the conventions than the things
we use constantly.
`filter` is the big one to me, as it is a common verb that people are likely to
use in their own `filtered-` methods. `reduce` is also a common verb, so it
does make sense to change to `reducing`, however I don’t imagine many people
will be writing their own `reducing-` methods, and similarly `mapping-`, so
these possibly fall more into the terms of art category for me; `filtered` is
the most important one. Besides, the word 'map' always suggests to me that a
new array/sequence will be returned, and never replace each item by mutation.
`filtered`: +1
`reducing`: +0.7
`mapping`: + 0.2
--
Brent Royal-Gordon
Architechies
_______________________________________________
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
