[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