[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)
Patrick Pijnappel
patrickpijnappel at gmail.com
Fri Jun 17 11:04:27 CDT 2016
>
> 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 at 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 at gmail.com <mailto:patrickpijnappel at 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 at gmail.com
>> <mailto:svabox at 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 at swift.org <mailto:swift-evolution at swift.org>
>> <mailto:swift-evolution at swift.org
>>
>> <mailto:swift-evolution at 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 at swift.org
>> <mailto:swift-evolution at swift.org>
>> <mailto:swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160617/3ecd3590/attachment.html>
More information about the swift-evolution
mailing list