On Jun 17, 2016, at 12:04 PM, Patrick Pijnappel via swift-evolution <swift-evolution@swift.org> wrote:
You could make the exact same arguments about `sin`.
– What sin(x) should do is unambiguous, unlike array.filter { ... }.
– There's very significant brevity issues here, e.g. hyperbolicArcTangent() vs atanh().
– The relevant metric of the strength of a term of art would be for how many users it already is a very much ingrained term (i.e. not how long it has been around). For sin() this is the case for pretty much anyone who has done high-school math. Conversely, map/filter/reduce will only be significantly ingrained for experienced users of languages that are functionally-centered enough to regularly use these, which is a much smaller percentage (though not insignificant).
Let me turn your question around: What concrete benefits do we gain from modifying terms which are extremely widely recognized? It is not consistent, but is there any reason to believe that causes actual confusion? If not, then why fix what isn't broken?
The benefits of renaming:
– It makes learning easier as it establishes a consistent way to read Swift methods right from the start.
– It would help users in intuitively learning consistent naming for their own methods, even if they haven't read the API guidelines.
– It allows defining e.g. an in-place filter variant.
I agree with your points on the problems with dropFirst/dropLast btw.
On Fri, Jun 17, 2016 at 4:05 PM, Vladimir.S <svabox@gmail.com <mailto:svabox@gmail.com>> wrote:
On 17.06.2016 15:58, Patrick Pijnappel wrote:
I suggest to leave map+flatMap+reduce as-is as true terms-of-art
Question still stands, what benefits do we gain from using the /exact/
terms that are not present in the slightly modified ones?
I don't know :-) I just see that many against renaming of map/filter/reduce/etc and suggest a compromise : we leave map/reduce as-is, but nothing else should be an exception to the naming rules.
On Fri, Jun 17, 2016 at 2:26 PM, Patrick Pijnappel > <patrickpijnappel@gmail.com <mailto:patrickpijnappel@gmail.com> <mailto:patrickpijnappel@gmail.com <mailto:patrickpijnappel@gmail.com>>> wrote:
`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
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.
The point the proposal raises is that the modified versions preserve
the the terms of art in all the senses that matter (i.e. all the
benefits like recognition etc. still apply).
On Fri, Jun 17, 2016 at 2:12 PM, Vladimir.S <svabox@gmail.com <mailto:svabox@gmail.com> > <mailto:svabox@gmail.com <mailto:svabox@gmail.com>>> wrote:
On 17.06.2016 8:02, Patrick Pijnappel via swift-evolution wrote:
-1, for the same reasons stated on the thread. These are
neither
guaranteed to be mutating or non-mutating until you get to
Collection.
Changing map() to mapped() would be lying to the developer
some of the
time about the mutability of the interface.
-DW
Actually the -ed/-ing suffix is *not *intended to guarantee
non-mutatability. It merely communicates whether it is a
"return-a-transformed-version-of-the-instance"-type method as
opposed to an
in-place mutation. Clearly these are not in-place forms. Note
that this is
my interpretation of the intent of the guidelines (or what
should be the
intent) – if the core team agrees perhaps this deserves
clarification in
the document.
Totally agree with you. I also understand this rule as separation
of "in-place"/"returns transformed version". I.e. the suffix should
say just "result of this operation will be returned and should be
assigned to other instance variable". Otherwise, as I understand,
ANY method that will touch or iterate the Sequence *could* mutate
it and so potentially we should have no -ing/-ed methods for
Sequence - no?
These functions are different than for example `sort`
because there
can’t be a general mutating method of `map`. A variable of
type `[A]`
can’t be mutated to hold a `[B]` which would be the result
of a map
from `A -> B`.
There could definitely be an in-place variant of filter. While
a /fully/
general method would not be possible for the others, an user might
reasonable expect in-place variants of map/flatMap if T == U as
with e.g. {
$0 * 2 } or Optionals, and of dropFirst/dropLast if SubSequence
== Sequence
as with e.g. String.
Also note that the -ed/-ing rule should not be merely for
ambiguous cases,
it should tell the user that the main use of the method is
returning a
transformed version of the instance. Having this be a rule you
can depend
on is important.
+1
-1 The Term of Art argument is very strong with these
functions. I
prefer them as-is.
What specific benefits do we obtain from using the /exact
/terms of art vs.
the very slightly modified versions proposed?
Although I believe we can leave map&reduce as-is, I can understand
if we'll change them to mapped/reduced and will have consistent
naming everywhere, don't think this will cause any confusion for
one who will start to use them. In any case, we can add a hint in
compiler like "did you mean 'mapped'?".
On Fri, Jun 17, 2016 at 3:24 AM, Brent Royal-Gordon via
swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
<mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>> wrote:
> The 'reduce()' at its core take an array of element and
reduce it to single element (could be of a different type) as
such it cannot ever be mutating (if one really want it, one
could reduce an array to the same array but it is not the goal
of the function). For this one it sound to me nearly like
asking to rename 'max()' to 'maxed()', 'count' to 'counted' or
implement a 'summed()' instead of a 'sum()' for [Int].
`max`, `count`, and `sum` are all nouns—at least in the
senses they are
meant in those calls—so they do not take the -ed/-ing
suffixes to form
immutable variants. Instead, they would take the `form`
prefix to form
mutable variants, if they had them.
`map`, `filter`, and `reduce`—at least in the senses they
must be
interpreted in for the names of those calls to make
sense—are verbs,
and so they *would* normally take -ed/-ing suffixes.
However, as
broadly-accepted terms of art, we have left them alone
until now.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
<mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution