[Discussion] Terms of Art Swiftification

[Erica_Sadun]

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

[dabrahams (Dave Abrahams)]

This discussion is already happening in
http://news.gmane.org/find-root.php?message_id=CAKA%3DjdbxiC_q0Fe%3DXc%3DmSWu7OtGxMgAQyb0QMA6_OaiiLB3foA%40mail.gmail.com

Do you really want to start over?

···

on Mon Jun 27 2016, Erica Sadun <swift-evolution@swift.org> wrote:

Under consideration is the resolution that "some terms of art while
appropriate to many FP languages, may be better served by using Swift
names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something
like .select() since that better matches what it does, IMO. “Filter”
is almost like the opposite word from what it should be since the
closure returning true is what decides what is included in the
results, not what is filtered *from* the results. I mean, yeah, I
can kind of understand the logic either way, but it’s always been
one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for
`filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams
replies:

Because `where(...)` is better.

Have at it.

--
Dave

[BigZaphod (Sean Heber)]

Here’s a perhaps unlikely “what if” idea that is tangentially related to the problem that FP and mathematical names are sometimes weird in Swift and often don’t have a place to “live” that makes sense.

Let’s say we add an ability to declare a function on a struct/protocol/class/enum as a “functionalAlias” (for lack of a better name) which creates both a normal method, but also an effectively global function of the same (or an alternate given) name for use in functional scenarios.

Example:

struct Float {
  @functionalAlias(floor) func roundedDown() -> Float { return … }
}

This would allow you to do this:

let value: Float = 42
let a = value.roundedDown()
let b = floor(value)

Essentially, the compiler generates something sort of like this for you:

extension Float {
  static func floor(_ v: Float) -> Float { return v.roundedDown() }
}

When looking up a global function, the compiler would include these generated static functions as if they were top-level functions and proceed pretty much like normal. If there is any ambiguity, since the auto-generated function are effectively declared as a static inside of another type, you could always disambiguate with “Float.floor” if necessary.

Obviously this is just brainstorming/talking out loud. Maybe this is silly. Maybe it’s terrible. (Probably both.)

l8r
Sean

···

On Jun 27, 2016, at 2:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

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

[Charlie_Monroe1 (Charlie Monroe)]

Erica had a nice list of various term-of-art usages among languages - it included filter, map, etc. - I just can't seem to find it anywhere. This nicely showed that there is only a few languages that name things differently, mostly C# and C++.

"filter" is nowadays quite a universal word that is in many languages - and I'm talking both about programming and a natural language. And I don't think that it goes against what one might be expecting - when you open a filter in the UI, you don't tick things that you don't want to see, but items that you *do* want to see.

I don't think that changing those names will add any additional value to the Swift language. I've personally had more issues with the naming of flatMap - it could have been called filterMap to stay in line of filtering by returning nil (flattening an array is in my head associated with flattening of an array of arrays). But it's a term of art and I got my head around it.

···

On Jun 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

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

[Patrick_Smith]

I liked Brent Royal-Gordon’s suggestion of `every(where:)`. Select is too abstract and SQLish, whereas ‘every’ is a basic english word that would look familiar in a Swift Playground.

Or `where(_:)` I could live with.

Patrick

···

On 28 Jun 2016, at 5:31 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

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

[BigZaphod (Sean Heber)]

And along a similar line of thinking, what about a @termOfArt() attribute that similarly redefines or provides additional names for things. This way the name in the standard library/etc would be the “Swift” version of the name - but there’d be a way to use it and find it even if you’re familiar with other names for the same feature.

@termOfArt(filter) func where(…)

etc.

There could then be migration tools in Xcode (and others) which do things like transform all of your termsOfArt usages into the standard Swift nomenclature if you want to migrate/standardize.

Again, maybe this is silly. On the one hand, I’m not a fan of multiple names for the same things. On the other hand, sometimes the best name for a thing depends on context.

l8r
Sean

···

On Jun 27, 2016, at 3:19 PM, Sean Heber <sean@fifthace.com> wrote:

Here’s a perhaps unlikely “what if” idea that is tangentially related to the problem that FP and mathematical names are sometimes weird in Swift and often don’t have a place to “live” that makes sense.

Let’s say we add an ability to declare a function on a struct/protocol/class/enum as a “functionalAlias” (for lack of a better name) which creates both a normal method, but also an effectively global function of the same (or an alternate given) name for use in functional scenarios.

Example:

struct Float {
@functionalAlias(floor) func roundedDown() -> Float { return … }
}

This would allow you to do this:

let value: Float = 42
let a = value.roundedDown()
let b = floor(value)

Essentially, the compiler generates something sort of like this for you:

extension Float {
static func floor(_ v: Float) -> Float { return v.roundedDown() }
}

When looking up a global function, the compiler would include these generated static functions as if they were top-level functions and proceed pretty much like normal. If there is any ambiguity, since the auto-generated function are effectively declared as a static inside of another type, you could always disambiguate with “Float.floor” if necessary.

Obviously this is just brainstorming/talking out loud. Maybe this is silly. Maybe it’s terrible. (Probably both.)

l8r
Sean

On Jun 27, 2016, at 2:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

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

[masters3d]

I would support a rename of filter to the right name. This is a little silly but wouldn't select(…) become selecting(…) with the naming rules? I think where(…) would only make sense if it was lazy by default.
There probably needs to be a whole survey of names (seems kinda late for swift 3).
I would be afraid of a function type alias fractioning the language. Naming is hard.

···

On Jun 27, 2016, at 1:19 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

Here’s a perhaps unlikely “what if” idea that is tangentially related to the problem that FP and mathematical names are sometimes weird in Swift and often don’t have a place to “live” that makes sense.

Let’s say we add an ability to declare a function on a struct/protocol/class/enum as a “functionalAlias” (for lack of a better name) which creates both a normal method, but also an effectively global function of the same (or an alternate given) name for use in functional scenarios.

Example:

struct Float {
@functionalAlias(floor) func roundedDown() -> Float { return … }
}

This would allow you to do this:

let value: Float = 42
let a = value.roundedDown()
let b = floor(value)

Essentially, the compiler generates something sort of like this for you:

extension Float {
static func floor(_ v: Float) -> Float { return v.roundedDown() }
}

When looking up a global function, the compiler would include these generated static functions as if they were top-level functions and proceed pretty much like normal. If there is any ambiguity, since the auto-generated function are effectively declared as a static inside of another type, you could always disambiguate with “Float.floor” if necessary.

Obviously this is just brainstorming/talking out loud. Maybe this is silly. Maybe it’s terrible. (Probably both.)

l8r
Sean

On Jun 27, 2016, at 2:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

_______________________________________________
swift-evolution mailing list
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

[Karl]

This is kind of the reverse of how operators work, isn’t it? (Or used to work, I don’t know if they’ve changed since the last time I looked)

We’re definitely having lots of discussions about how the ‘swifty’ way to structure the stdlib would seem a bit alien to people from other languages. C developers wouldn’t discover `(4.4).floor()` or `(4.4).roundedDown()` because their primitive value types don’t have instance methods. At the same time, we seem to have resolved against global functions.

Is better documentation maybe the answer? Perhaps these could be examples in the Swift programming guide. When it comes to functions like `filter`, perhaps a glossary? The standard library is intentionally kept small, so it could be manageable to just keep a mapping of commonly-confused functions.

Ultimately, people are going to a) check code completion, and failing that b) google it. For things like ‘filter’, it’s a one-off friction of a handful of seconds. Maybe we should just be more ruthless; maybe we can afford to be these days.

Karl

···

On 27 Jun 2016, at 22:19, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

Here’s a perhaps unlikely “what if” idea that is tangentially related to the problem that FP and mathematical names are sometimes weird in Swift and often don’t have a place to “live” that makes sense.

Let’s say we add an ability to declare a function on a struct/protocol/class/enum as a “functionalAlias” (for lack of a better name) which creates both a normal method, but also an effectively global function of the same (or an alternate given) name for use in functional scenarios.

Example:

struct Float {
@functionalAlias(floor) func roundedDown() -> Float { return … }
}

This would allow you to do this:

let value: Float = 42
let a = value.roundedDown()
let b = floor(value)

Essentially, the compiler generates something sort of like this for you:

extension Float {
static func floor(_ v: Float) -> Float { return v.roundedDown() }
}

When looking up a global function, the compiler would include these generated static functions as if they were top-level functions and proceed pretty much like normal. If there is any ambiguity, since the auto-generated function are effectively declared as a static inside of another type, you could always disambiguate with “Float.floor” if necessary.

Obviously this is just brainstorming/talking out loud. Maybe this is silly. Maybe it’s terrible. (Probably both.)

L8r
Sean

[BigZaphod (Sean Heber)]

The trouble with this line of reasoning, IMO, is that it is what led to the floppy disk becoming the “universal” save icon for years and years. Apple has spent considerable effort in macOS and iOS trying to show that you don’t really need a save button at all most of the time - it turns out that auto-save by default is what people expect. Flip the logic on it’s head!

I fear that by adhering strongly to terms of art, we could be looking at a floppy-save-icon scenario over time. What if there are simply better ways of doing these things? What if the names themselves are blinding us to other alternatives?

One of the purposes of my thought of having aliases for functions/methods is that it would give us an obvious primary location for a function - inside of the correct type or protocol - that feels Swifty. It would allow us to use “proper” Swift names that read fluently according to the guidelines even if they are perhaps more verbose or nontraditional or even unusual. Then by mapping those names to the existing common names, we can bring people along without too much initial pain while still allowing exploration of a new way to express things.

Swift already has a rather unusual rule in that statements are meant to read like english phrases. It is meant to have a kind of human language flow when read because code is read more than it is written. Virtually all existing terms of art were NOT created with that kind of consideration. How can Swift come into its own if it isn’t allowed to have its own names for things that work with its own rules? I mean, sure, not *every* name needs to change and not every word needs to change, but it feels to me like we’re just coming up with our own dialect of a “standard” language that’s no different than American english vs. British english when what I think we should be exploring is more along the lines of the differences between english vs. greek.

l8r
Sean

···

On Jun 28, 2016, at 12:31 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

Erica had a nice list of various term-of-art usages among languages - it included filter, map, etc. - I just can't seem to find it anywhere. This nicely showed that there is only a few languages that name things differently, mostly C# and C++.

"filter" is nowadays quite a universal word that is in many languages - and I'm talking both about programming and a natural language. And I don't think that it goes against what one might be expecting - when you open a filter in the UI, you don't tick things that you don't want to see, but items that you *do* want to see.

I don't think that changing those names will add any additional value to the Swift language. I've personally had more issues with the naming of flatMap - it could have been called filterMap to stay in line of filtering by returning nil (flattening an array is in my head associated with flattening of an array of arrays). But it's a term of art and I got my head around it.

On Jun 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

_______________________________________________
swift-evolution mailing list
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

[David_Ronnqvist (David Rönnqvist)]

Is this (below) the list you were referring to? (copied from: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered) )

- David

···

——————————————————————————————

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

* `map` is by far the strongest. It is universally supported among languages with higher-order collection operations, and is almost always called `map`. In Wikipedia's list of 32 languages with a `map` <Map (higher-order function) - Wikipedia <Map (higher-order function) - Wikipedia, we find (grouping together similar names like `map` and `maplist`, and double-counting languages with several aliases):

  Map: 19
  Collect: 3
  Apply: 3
  Special syntax: 2
  Select: 1 (C#, which uses it in the SQL-inspired LINQ)
  Transform: 1 (C++, which uses a bizarre signature involving an out parameter)
  ForEach: 1 (XPath)

* `filter` is supported nearly as widely as `map`, and the name `filter` is used nearly as consistently as `map`. Wikipedia lists 27 languages supporting a `filter`-style function, and `filter` is by far the most common choice, arguably favored even more consistently than `map` <Filter (higher-order function) - Wikipedia <https://en.wikipedia.org/wiki/Filter_(higher-order_function)&gt;&gt;:

  Filter: 17
  Select: 4
  Special syntax: 3
  FilteredArrayUsingPredicate: 1 (Foundation, doesn't actually take a closure)
  Where: 1 (C#, in LINQ)
  CopyIf: 1 (C++, bizarre signature)
  FindAll: 1
  Grep: 1
  RemoveIfNot: 1

* `reduce` is extremely popular among functional languages because it's a primitive list-handling operation, although it's a little less common among mainstream languages than the other two. It *does* actually have an alternate name, `fold`, which is nearly as common as `reduce`. However, languages using `fold` are usually those which support both leftward- and rightward-reducing versions of the operation, whereas languages using `reduce` usually don't. Swift falls into the second camp. From Wikipedia's 39-language list <Fold (higher-order function) - Wikipedia <https://en.wikipedia.org/wiki/Fold_(higher-order_function)&gt;&gt;:

  Reduce: 20 (with both left and right: 4)
  Fold: 18 (with both left and right: 12)
  Inject: 3
  Special syntax: 3
  Aggregate: 1 (C#, in LINQ)
  Accumulate: 1 (C++, bizarre signature)
  Partition: 1
  ToIterator: 1

On 28 Jun 2016, at 07:31, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

Erica had a nice list of various term-of-art usages among languages - it included filter, map, etc. - I just can't seem to find it anywhere. This nicely showed that there is only a few languages that name things differently, mostly C# and C++.

"filter" is nowadays quite a universal word that is in many languages - and I'm talking both about programming and a natural language. And I don't think that it goes against what one might be expecting - when you open a filter in the UI, you don't tick things that you don't want to see, but items that you *do* want to see.

I don't think that changing those names will add any additional value to the Swift language. I've personally had more issues with the naming of flatMap - it could have been called filterMap to stay in line of filtering by returning nil (flattening an array is in my head associated with flattening of an array of arrays). But it's a term of art and I got my head around it.

On Jun 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

_______________________________________________
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

[SlaunchaMan (Jeff Kelley)]

More generically, it could be something like @alias:

@alias(filter) func where(…)

This would allow this particular case to have another name, but also allow for things like alternate spellings.

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; | jeffkelley.org <http://jeffkelley.org/&gt;

···

On Jun 27, 2016, at 4:37 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

And along a similar line of thinking, what about a @termOfArt() attribute that similarly redefines or provides additional names for things. This way the name in the standard library/etc would be the “Swift” version of the name - but there’d be a way to use it and find it even if you’re familiar with other names for the same feature.

@termOfArt(filter) func where(…)

etc.

There could then be migration tools in Xcode (and others) which do things like transform all of your termsOfArt usages into the standard Swift nomenclature if you want to migrate/standardize.

Again, maybe this is silly. On the one hand, I’m not a fan of multiple names for the same things. On the other hand, sometimes the best name for a thing depends on context.

l8r
Sean

On Jun 27, 2016, at 3:19 PM, Sean Heber <sean@fifthace.com> wrote:

Here’s a perhaps unlikely “what if” idea that is tangentially related to the problem that FP and mathematical names are sometimes weird in Swift and often don’t have a place to “live” that makes sense.

Let’s say we add an ability to declare a function on a struct/protocol/class/enum as a “functionalAlias” (for lack of a better name) which creates both a normal method, but also an effectively global function of the same (or an alternate given) name for use in functional scenarios.

Example:

struct Float {
@functionalAlias(floor) func roundedDown() -> Float { return … }
}

This would allow you to do this:

let value: Float = 42
let a = value.roundedDown()
let b = floor(value)

Essentially, the compiler generates something sort of like this for you:

extension Float {
static func floor(_ v: Float) -> Float { return v.roundedDown() }
}

When looking up a global function, the compiler would include these generated static functions as if they were top-level functions and proceed pretty much like normal. If there is any ambiguity, since the auto-generated function are effectively declared as a static inside of another type, you could always disambiguate with “Float.floor” if necessary.

Obviously this is just brainstorming/talking out loud. Maybe this is silly. Maybe it’s terrible. (Probably both.)

l8r
Sean

On Jun 27, 2016, at 2:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

_______________________________________________
swift-evolution mailing list
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

[Charlie_Monroe1 (Charlie Monroe)]

Yes. Sorry, it was composed by Brent - not sure why I thought it was Erica - that is why I couldn't find it. Thanks!

···

On Jun 28, 2016, at 9:11 AM, David Rönnqvist <david.ronnqvist@gmail.com> wrote:

Is this (below) the list you were referring to? (copied from: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered) )

- David

——————————————————————————————

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

* `map` is by far the strongest. It is universally supported among languages with higher-order collection operations, and is almost always called `map`. In Wikipedia's list of 32 languages with a `map` <Map (higher-order function) - Wikipedia <Map (higher-order function) - Wikipedia, we find (grouping together similar names like `map` and `maplist`, and double-counting languages with several aliases):

  Map: 19
  Collect: 3
  Apply: 3
  Special syntax: 2
  Select: 1 (C#, which uses it in the SQL-inspired LINQ)
  Transform: 1 (C++, which uses a bizarre signature involving an out parameter)
  ForEach: 1 (XPath)

* `filter` is supported nearly as widely as `map`, and the name `filter` is used nearly as consistently as `map`. Wikipedia lists 27 languages supporting a `filter`-style function, and `filter` is by far the most common choice, arguably favored even more consistently than `map` <Filter (higher-order function) - Wikipedia <https://en.wikipedia.org/wiki/Filter_(higher-order_function)&gt;&gt;:

  Filter: 17
  Select: 4
  Special syntax: 3
  FilteredArrayUsingPredicate: 1 (Foundation, doesn't actually take a closure)
  Where: 1 (C#, in LINQ)
  CopyIf: 1 (C++, bizarre signature)
  FindAll: 1
  Grep: 1
  RemoveIfNot: 1

* `reduce` is extremely popular among functional languages because it's a primitive list-handling operation, although it's a little less common among mainstream languages than the other two. It *does* actually have an alternate name, `fold`, which is nearly as common as `reduce`. However, languages using `fold` are usually those which support both leftward- and rightward-reducing versions of the operation, whereas languages using `reduce` usually don't. Swift falls into the second camp. From Wikipedia's 39-language list <Fold (higher-order function) - Wikipedia <https://en.wikipedia.org/wiki/Fold_(higher-order_function)&gt;&gt;:

  Reduce: 20 (with both left and right: 4)
  Fold: 18 (with both left and right: 12)
  Inject: 3
  Special syntax: 3
  Aggregate: 1 (C#, in LINQ)
  Accumulate: 1 (C++, bizarre signature)
  Partition: 1
  ToIterator: 1

On 28 Jun 2016, at 07:31, Charlie Monroe via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Erica had a nice list of various term-of-art usages among languages - it included filter, map, etc. - I just can't seem to find it anywhere. This nicely showed that there is only a few languages that name things differently, mostly C# and C++.

"filter" is nowadays quite a universal word that is in many languages - and I'm talking both about programming and a natural language. And I don't think that it goes against what one might be expecting - when you open a filter in the UI, you don't tick things that you don't want to see, but items that you *do* want to see.

I don't think that changing those names will add any additional value to the Swift language. I've personally had more issues with the naming of flatMap - it could have been called filterMap to stay in line of filtering by returning nil (flattening an array is in my head associated with flattening of an array of arrays). But it's a term of art and I got my head around it.

On Jun 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

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

[Shawn_Erickson]

I also feel that Swift should be held "hostage" to a term of art especially
if the term is fairly badly named and/or unswifty. I feel the term of art
can incorporated in the API docs and possibly expressed by the alias
concept that has been discussed.

I strongly encourage going with a swiftly name for things first and only
then back peddling after considering the range of terms of art seen in
other languages.

-Shawn

···

On Tue, Jun 28, 2016 at 6:38 AM Sean Heber via swift-evolution < swift-evolution@swift.org> wrote:

The trouble with this line of reasoning, IMO, is that it is what led to
the floppy disk becoming the “universal” save icon for years and years.
Apple has spent considerable effort in macOS and iOS trying to show that
you don’t really need a save button at all most of the time - it turns out
that auto-save by default is what people expect. Flip the logic on it’s
head!

I fear that by adhering strongly to terms of art, we could be looking at a
floppy-save-icon scenario over time. What if there are simply better ways
of doing these things? What if the names themselves are blinding us to
other alternatives?

One of the purposes of my thought of having aliases for functions/methods
is that it would give us an obvious primary location for a function -
inside of the correct type or protocol - that feels Swifty. It would allow
us to use “proper” Swift names that read fluently according to the
guidelines even if they are perhaps more verbose or nontraditional or even
unusual. Then by mapping those names to the existing common names, we can
bring people along without too much initial pain while still allowing
exploration of a new way to express things.

Swift already has a rather unusual rule in that statements are meant to
read like english phrases. It is meant to have a kind of human language
flow when read because code is read more than it is written. Virtually all
existing terms of art were NOT created with that kind of consideration. How
can Swift come into its own if it isn’t allowed to have its own names for
things that work with its own rules? I mean, sure, not *every* name needs
to change and not every word needs to change, but it feels to me like we’re
just coming up with our own dialect of a “standard” language that’s no
different than American english vs. British english when what I think we
should be exploring is more along the lines of the differences between
english vs. greek.

l8r
Sean

> On Jun 28, 2016, at 12:31 AM, Charlie Monroe via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Erica had a nice list of various term-of-art usages among languages - it
included filter, map, etc. - I just can't seem to find it anywhere. This
nicely showed that there is only a few languages that name things
differently, mostly C# and C++.
>
> "filter" is nowadays quite a universal word that is in many languages -
and I'm talking both about programming and a natural language. And I don't
think that it goes against what one might be expecting - when you open a
filter in the UI, you don't tick things that you don't want to see, but
items that you *do* want to see.
>
> I don't think that changing those names will add any additional value to
the Swift language. I've personally had more issues with the naming of
flatMap - it could have been called filterMap to stay in line of filtering
by returning nil (flattening an array is in my head associated with
flattening of an array of arrays). But it's a term of art and I got my head
around it.
>
>> On Jun 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> Under consideration is the resolution that "some terms of art while
appropriate to many FP languages, may be better served by using Swift
names."
>>
>> Consider, for example, `filter(_:)`. Sean Heber writes,
>>
>>> Just tossing my vote in the hat for renaming .filter() to something
like .select() since that better matches what it does, IMO. “Filter” is
almost like the opposite word from what it should be since the closure
returning true is what decides what is included in the results, not what is
filtered *from* the results. I mean, yeah, I can kind of understand the
logic either way, but it’s always been one of those strange mental
gymnastics things."
>>
>> When asked "Shouldn't there be a term of art exemption for
`filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams
replies:
>>
>>> Because `where(...)` is better.
>>
>> Have at it.
>>
>> -- E
>>
>> _______________________________________________
>> swift-evolution mailing list
>> 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

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

[BigZaphod (Sean Heber)]

I considered suggesting that at first - and maybe that’d be easier/better - but I liked the idea of preserving the *intent* of the alias in different scenerios. Not sure. That could be hammered out assuming people thought this was a good direction to even consider vs. just picking a single name for things and having that be that. :)

l8r
Sean

···

On Jun 27, 2016, at 3:44 PM, Jeff Kelley <slaunchaman@gmail.com> wrote:

More generically, it could be something like @alias:

@alias(filter) func where(…)

This would allow this particular case to have another name, but also allow for things like alternate spellings.

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan | jeffkelley.org

On Jun 27, 2016, at 4:37 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

And along a similar line of thinking, what about a @termOfArt() attribute that similarly redefines or provides additional names for things. This way the name in the standard library/etc would be the “Swift” version of the name - but there’d be a way to use it and find it even if you’re familiar with other names for the same feature.

@termOfArt(filter) func where(…)

etc.

There could then be migration tools in Xcode (and others) which do things like transform all of your termsOfArt usages into the standard Swift nomenclature if you want to migrate/standardize.

Again, maybe this is silly. On the one hand, I’m not a fan of multiple names for the same things. On the other hand, sometimes the best name for a thing depends on context.

l8r
Sean

On Jun 27, 2016, at 3:19 PM, Sean Heber <sean@fifthace.com> wrote:

Here’s a perhaps unlikely “what if” idea that is tangentially related to the problem that FP and mathematical names are sometimes weird in Swift and often don’t have a place to “live” that makes sense.

Let’s say we add an ability to declare a function on a struct/protocol/class/enum as a “functionalAlias” (for lack of a better name) which creates both a normal method, but also an effectively global function of the same (or an alternate given) name for use in functional scenarios.

Example:

struct Float {
@functionalAlias(floor) func roundedDown() -> Float { return … }
}

This would allow you to do this:

let value: Float = 42
let a = value.roundedDown()
let b = floor(value)

Essentially, the compiler generates something sort of like this for you:

extension Float {
static func floor(_ v: Float) -> Float { return v.roundedDown() }
}

When looking up a global function, the compiler would include these generated static functions as if they were top-level functions and proceed pretty much like normal. If there is any ambiguity, since the auto-generated function are effectively declared as a static inside of another type, you could always disambiguate with “Float.floor” if necessary.

Obviously this is just brainstorming/talking out loud. Maybe this is silly. Maybe it’s terrible. (Probably both.)

l8r
Sean

On Jun 27, 2016, at 2:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names."

Consider, for example, `filter(_:)`. Sean Heber writes,

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered *from* the results. I mean, yeah, I can kind of understand the logic either way, but it’s always been one of those strange mental gymnastics things."

When asked "Shouldn't there be a term of art exemption for `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams replies:

Because `where(...)` is better.

Have at it.

-- E

_______________________________________________
swift-evolution mailing list
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