[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

Vladimir.S svabox at gmail.com
Fri Jun 17 09:05:07 CDT 2016


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
>
>
>


More information about the swift-evolution mailing list