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

Question still stands, what benefits do we gain from using the exact terms that are not present in the slightly modified ones?

Instant, unambiguous recognition.

Look. You could make the exact same arguments about `sin`. We could create a `sine()` method on FloatingPoint and install a dummy `sin(_:)` function with a `renamed` attribute pointing to it. Why don't we do that? Because it's not the terminology used for that domain. There is a universal convention, stretching back hundreds of years, for how you write "get the sine of this number", and `n.sine()` is not that convention, so we don't use it.

Similarly, there is a nearly universal convention, stretching back to Lisp's `maplist` function in 1959 (!!!), pointing at the term `map`. `reduce` dates back to APL in 1962, although of course that was the term used in the documentation, since APL relied so heavily on operators. These terms are steeped in history as rich as anything in programming. By sticking to the exact terms, there is no question that yes, this is the same function programmers have been using since the Eisenhower administration.

By contrast, changing the name would seem to hint that it *isn't* the standard `map` function. Maybe Swift, like Java, calls its dictionaries `Map`s, and `mapped` or `mapping` is an operation to convert an array into a `Map`. And even if it's not confusing, it's going to confound the muscle memory of programmers who use both Swift and another language with higher-order list functions.

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?

That's why I want to focus on the first/last/prefix/suffix methods. There I see real problems: misleading names, tangled and unclear relationships, and little reason to tolerate the situation to preserve terms of art. Renaming `map`, `reduce`, and `filter`, by contrast, seem to be mostly about consistency for the sake of consistency, not consistency for the sake of concrete benefits.

···

--
Brent Royal-Gordon
Architechies

`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> 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>> 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>
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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?

···

On Fri, Jun 17, 2016 at 2:26 PM, Patrick Pijnappel < 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> 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>> 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>
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

     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 17.06.2016 15:58, Patrick Pijnappel wrote:

On Fri, Jun 17, 2016 at 2:26 PM, Patrick Pijnappel > <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>> 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>>> 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>>
                https://lists.swift.org/mailman/listinfo/swift-evolution

            _______________________________________________
            swift-evolution mailing list
            swift-evolution@swift.org <mailto:swift-evolution@swift.org>
            https://lists.swift.org/mailman/listinfo/swift-evolution

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> 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>> 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>> 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>>> 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>>
                https://lists.swift.org/mailman/listinfo/swift-evolution

            _______________________________________________
            swift-evolution mailing list
            swift-evolution@swift.org <mailto:swift-evolution@swift.org>
            https://lists.swift.org/mailman/listinfo/swift-evolution

+1 for consistency.

—A

···

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

– What sin(x) should do is unambiguous, unlike array.filter { ... }.

A decent argument label, like `including` or even `to`, would fix the name `filter`. And as I said, if we feel `filter` is unsalvageable, the alternate Smalltalk-lineage `select` is clearer.

– There's very significant brevity issues here, e.g. hyperbolicArcTangent() vs atanh().

Sure, but `mappingAndFlattening(to:)` would have brevity issues as well. (You didn't think the API Guidelines merely meant "add -ed or -ing to everything", did you?)

– 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).

I think "languages that are functionally-centered enough to regularly use these" makes this set of languages sound rather smaller than it really is. The languages with C in their names—C, C++, Objective-C, and C#—are almost the only ones in modern use which *don't* include higher-order functions. Few people would regard Perl, Javascript, Java, Python, or Ruby as "functional" languages, but all of them support `map`. If you look at RedMonk's list of 21 popular languages <http://fossbytes.com/21-top-programming-languages-on-github-and-stack-overflowjanuary-2016/&gt;:

* 1 (CSS) has no real concept of lists or list operations.
* 2 (shell and C) do not have closures.
* 1 (Go) could support `map`, but K&R still think it's 1973.
* 1 (Objective-C) could support `map`, but...well, if the Foundation guys want to tell us why they don't, they know where to find us.
* 16 have a version of `map`:
  * 1 (Matlab) has vectorization features which act like an implicit `map`.
  * 2 (C# and Visual Basic) have a `select` operation from LINQ
  * 3 (C++, R, and Groovy) have other names for `map`
  * 10 (Javascript, Java, PHP, Python, Ruby, Perl, Scala, Go, Haskell, Swift, and Clojure) call it `map`.

Of 16 languages with `map`, Scala, Haskell, Clojure, and maybe R and Matlab would typically be considered functional, and all of those are in the bottom half of the list. The other 11 languages with a version of `map` are all mainstream multi-paradigm languages of the sort people coming to Swift might be familiar with.

In short: Higher-order functions are not a specialized feature that only the functional eggheads use. Outside of a few small pockets—one of which is native Apple apps—they are a pervasive feature of modern programming environments. They are the rule, not the exception.

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.

These are basically two ways of stating the same point, which again, is not considered strong enough to overcome strong terms-of-art in other areas.

– It allows defining e.g. an in-place filter variant.

Several people have mentioned this could be done, but has anyone actually *asked* for it? And if it did exist, wouldn't it be better to offer this functionality as a `remove(where:)` function, matching existing methods like `first(where:)` and `index(where:)`?

(Actually, if we're going to rename `filter`, `where` might not be a terrible name. It's valid after a dot, but not without one.)

Even if we *do* want to offer it for `filter`, the others are not good candidates for mutating variants. Mutating `map` could only be offered on certain sub-protocols of `Collection`, could not be guaranteed to be in-place (and probably wouldn't be for most collection types), and would have a severely restricted set of use cases compared to its nonmutating equivalent. Mutating `flatMap` would suffer even more from these limitations, making it desperately tricky to implement. And `reduce` simply couldn't be offered at all.

I agree with your points on the problems with dropFirst/dropLast btw.

Incidentally, I just noticed that `removeFirst(_:)`/`removeLast(_:)` ought to get this treatment too.

I'll see if I can write up at least a sketch of what I'd like to do to these methods in the next few days, but I'm busy today preparing for the local (Orange County, CA) Apple community's post-WWDC event. Need to come up with something to talk about. :^)

···

--
Brent Royal-Gordon
Architechies

Sure, but `mappingAndFlattening(to:)` would have brevity issues as well.

My point was that if you want to transform sin() -> sine() you'd be pretty
much forced to also do atanh() -> hyperbolicArcTangent(). However the
proposed transformation is for flatMap() to flatMapped(), which doesn't
have any brevity issues and is still very close to the exact term of art.

Higher-order functions are not a specialized feature that only the

functional eggheads use. Outside of a few small pockets—one of which is
native Apple apps—they are a pervasive feature of modern programming
environments. They are the rule, not the exception.

They do have significant usage, but the term of art will not be an
"ingrained term" for any of the following:
– Users new to programming.
– Users from languages that do not have these functions, or include them
under a different name.
– Users from languages that do have these functions under these names, but
haven't used them so regularly as to become an ingrained term. Which I'd
estimate is a large group: Personally I've used most of the mainstream
languages on your list, some for a very long time, without using these
functions very much at all.

Nevertheless I'm also definitely in favor of keeping *the terms of art as
stems (*i.e. not moving to different words altogether) so we retain 90% of
the benefits, but just slightly modifying them.

···

On Sat, Jun 18, 2016 at 4:13 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

> – What sin(x) should do is unambiguous, unlike array.filter { ... }.

A decent argument label, like `including` or even `to`, would fix the name
`filter`. And as I said, if we feel `filter` is unsalvageable, the
alternate Smalltalk-lineage `select` is clearer.

> – There's very significant brevity issues here, e.g.
hyperbolicArcTangent() vs atanh().

Sure, but `mappingAndFlattening(to:)` would have brevity issues as well.
(You didn't think the API Guidelines merely meant "add -ed or -ing to
everything", did you?)

> – 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).

I think "languages that are functionally-centered enough to regularly use
these" makes this set of languages sound rather smaller than it really is.
The languages with C in their names—C, C++, Objective-C, and C#—are almost
the only ones in modern use which *don't* include higher-order functions.
Few people would regard Perl, Javascript, Java, Python, or Ruby as
"functional" languages, but all of them support `map`. If you look at
RedMonk's list of 21 popular languages <
21 Top Programming Languages On GitHub And Stack Overflow
>:

* 1 (CSS) has no real concept of lists or list operations.
* 2 (shell and C) do not have closures.
* 1 (Go) could support `map`, but K&R still think it's 1973.
* 1 (Objective-C) could support `map`, but...well, if the Foundation guys
want to tell us why they don't, they know where to find us.
* 16 have a version of `map`:
        * 1 (Matlab) has vectorization features which act like an implicit
`map`.
        * 2 (C# and Visual Basic) have a `select` operation from LINQ
        * 3 (C++, R, and Groovy) have other names for `map`
        * 10 (Javascript, Java, PHP, Python, Ruby, Perl, Scala, Go,
Haskell, Swift, and Clojure) call it `map`.

Of 16 languages with `map`, Scala, Haskell, Clojure, and maybe R and
Matlab would typically be considered functional, and all of those are in
the bottom half of the list. The other 11 languages with a version of `map`
are all mainstream multi-paradigm languages of the sort people coming to
Swift might be familiar with.

In short: Higher-order functions are not a specialized feature that only
the functional eggheads use. Outside of a few small pockets—one of which is
native Apple apps—they are a pervasive feature of modern programming
environments. They are the rule, not the exception.

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

These are basically two ways of stating the same point, which again, is
not considered strong enough to overcome strong terms-of-art in other areas.

> – It allows defining e.g. an in-place filter variant.

Several people have mentioned this could be done, but has anyone actually
*asked* for it? And if it did exist, wouldn't it be better to offer this
functionality as a `remove(where:)` function, matching existing methods
like `first(where:)` and `index(where:)`?

(Actually, if we're going to rename `filter`, `where` might not be a
terrible name. It's valid after a dot, but not without one.)

Even if we *do* want to offer it for `filter`, the others are not good
candidates for mutating variants. Mutating `map` could only be offered on
certain sub-protocols of `Collection`, could not be guaranteed to be
in-place (and probably wouldn't be for most collection types), and would
have a severely restricted set of use cases compared to its nonmutating
equivalent. Mutating `flatMap` would suffer even more from these
limitations, making it desperately tricky to implement. And `reduce` simply
couldn't be offered at all.

> I agree with your points on the problems with dropFirst/dropLast btw.

Incidentally, I just noticed that `removeFirst(_:)`/`removeLast(_:)` ought
to get this treatment too.

I'll see if I can write up at least a sketch of what I'd like to do to
these methods in the next few days, but I'm busy today preparing for the
local (Orange County, CA) Apple community's post-WWDC event. Need to come
up with something to talk about. :^)

--
Brent Royal-Gordon
Architechies

– What sin(x) should do is unambiguous, unlike array.filter { ... }.

A decent argument label, like `including` or even `to`, would fix the
name `filter`.

  x.filter(to: isPrime)

? I don't think that reads nearly as well as

  x.where(isPrime)

even when considering the term-of-art recognizability.

And as I said, if we feel `filter` is unsalvageable, the alternate
Smalltalk-lineage `select` is clearer.

Than “where?”

– There's very significant brevity issues here, e.g. hyperbolicArcTangent() vs atanh().

Sure, but `mappingAndFlattening(to:)` would have brevity issues as
well. (You didn't think the API Guidelines merely meant "add -ed or
-ing to everything", did you?)

That would, IMO, be:

  x.flatMapping(fourCopies)

···

on Fri Jun 17 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:

--
Dave

And as I said, if we feel `filter` is unsalvageable, the alternate
Smalltalk-lineage `select` is clearer.

Than “where?”

No, than "filter". "filter" is the most common name, but "select" is also fairly popular, and doesn't have the same ambiguity issues as "filter". "where" is slightly clearer than "filter", but it finds little precedent in other languages (the only other use I'm aware of is in SQL and LINQ, which are declarative), ignores the normal grammar rules for a method ("where" is an adverb, not a noun or verb), and is already a language keyword which has been overloaded with several slightly different semantics, including list filtering in the `for` loop.

– There's very significant brevity issues here, e.g. hyperbolicArcTangent() vs atanh().

Sure, but `mappingAndFlattening(to:)` would have brevity issues as
well. (You didn't think the API Guidelines merely meant "add -ed or
-ing to everything", did you?)

That would, IMO, be:

x.flatMapping(fourCopies)

Why? If we're leaving the terms of art behind, we probably ought to consider that the base name `flatMap` is rather opaque to new users; I've seen people in my NSCoder group struggle with it. For that matter, `map` and `reduce` aren't the best names either.

I can understand wanting to keep terms of art even if they're a little opaque. I can understand wanting to invent new, clear terms. I cannot understand wanting to make minor cosmetic changes to the terms of art while still keeping the parts that make them opaque. You lose many of the benefits of a term of art *and* most of the benefits of a new term.

It's a bit like painting a single wall in a room: You can match the existing color exactly and have it look seamless, or you can choose an obviously different color and make a statement, but choosing a slightly different shade of the existing color does neither of those things.

···

--
Brent Royal-Gordon
Architechies

And as I said, if we feel `filter` is unsalvageable, the alternate
Smalltalk-lineage `select` is clearer.

Than “where?”

No, than "filter". "filter" is the most common name, but "select" is
also fairly popular, and doesn't have the same ambiguity issues as
"filter".

True.

"where" is slightly clearer than "filter", but it finds little
precedent in other languages (the only other use I'm aware of is in
SQL and LINQ, which are declarative), ignores the normal grammar rules
for a method ("where" is an adverb, not a noun or verb),

There's no rule that says the base name should be a noun or verb. The
rule says that *usage* should be a verb *phrase* or noun *phrase.*

and is already a language keyword which has been overloaded with
several slightly different semantics, including list filtering in the
`for` loop.

– There's very significant brevity issues here, e.g. hyperbolicArcTangent() vs atanh().

Sure, but `mappingAndFlattening(to:)` would have brevity issues as
well. (You didn't think the API Guidelines merely meant "add -ed or
-ing to everything", did you?)

That would, IMO, be:

x.flatMapping(fourCopies)

Why?

Because one (flat)maps a function over a sequence. The function is the direct
object.

If we're leaving the terms of art behind, we probably ought to
consider that the base name `flatMap` is rather opaque to new users;
I've seen people in my NSCoder group struggle with it. For that
matter, `map` and `reduce` aren't the best names either.

I can understand wanting to keep terms of art even if they're a little
opaque. I can understand wanting to invent new, clear terms. I cannot
understand wanting to make minor cosmetic changes to the terms of art
while still keeping the parts that make them opaque. You lose many of
the benefits of a term of art *and* most of the benefits of a new
term.

I agree. However, we really need to discuss
http://article.gmane.org/gmane.comp.lang.swift.evolution/21046 before we
go any further down this road.

···

on Mon Jun 20 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:

--
Dave

And as I said, if we feel `filter` is unsalvageable, the alternate
Smalltalk-lineage `select` is clearer.

Than “where?”

No, than "filter". "filter" is the most common name, but "select" is

Why not x.select(where: isPrime) ? IMO this is more clear than
x.select(filter: isPrime) and looks similar to `where` in other parts of language.

also fairly popular, and doesn't have the same ambiguity issues as
"filter". "where" is slightly clearer than "filter", but it finds little
precedent in other languages (the only other use I'm aware of is in SQL
and LINQ, which are declarative), ignores the normal grammar rules for a

FWIW `Where` is used as method also in c#

Example:
IEnumerable<int> numQuery2 = numbers.Where(num => num % 2 == 0).OrderBy(n => n);

···

On 21.06.2016 0:56, Brent Royal-Gordon via swift-evolution wrote:

method ("where" is an adverb, not a noun or verb), and is already a
language keyword which has been overloaded with several slightly
different semantics, including list filtering in the `for` loop.

– There's very significant brevity issues here, e.g.
hyperbolicArcTangent() vs atanh().

Sure, but `mappingAndFlattening(to:)` would have brevity issues as
well. (You didn't think the API Guidelines merely meant "add -ed or
-ing to everything", did you?)

That would, IMO, be:

x.flatMapping(fourCopies)

Why? If we're leaving the terms of art behind, we probably ought to
consider that the base name `flatMap` is rather opaque to new users;
I've seen people in my NSCoder group struggle with it. For that matter,
`map` and `reduce` aren't the best names either.

I can understand wanting to keep terms of art even if they're a little
opaque. I can understand wanting to invent new, clear terms. I cannot
understand wanting to make minor cosmetic changes to the terms of art
while still keeping the parts that make them opaque. You lose many of
the benefits of a term of art *and* most of the benefits of a new term.

It's a bit like painting a single wall in a room: You can match the
existing color exactly and have it look seamless, or you can choose an
obviously different color and make a statement, but choosing a slightly
different shade of the existing color does neither of those things.

FWIW `Where` is used as method also in c#

Example:
IEnumerable<int> numQuery2 = numbers.Where(num => num % 2 == 0).OrderBy(n => n);

C# Where is part of LINQ; even when called as a method instead of as special syntax, it still has lazy, declarative behavior.

···

--
Brent Royal-Gordon
Architechies

I have some reasons worthy of consideration, but would prefer to
postpone this discussion until after we deal with
http://mid.gmane.org/m27fdjzh72.fsf%40fripp.apple.com

···

on Tue Jun 21 2016, "Vladimir.S via swift-evolution" <swift-evolution@swift.org> wrote:

On 21.06.2016 0:56, Brent Royal-Gordon via swift-evolution wrote:

And as I said, if we feel `filter` is unsalvageable, the alternate
Smalltalk-lineage `select` is clearer.

Than “where?”

No, than "filter". "filter" is the most common name, but "select" is

Why not x.select(where: isPrime) ? IMO this is more clear than
x.select(filter: isPrime) and looks similar to `where` in other parts
of language.

--
Dave