[Proposal] Refining Identifier and Operator Symbology


(Jon Hull) #1

An EXTREME -1 from me as well. The restrictions on operators is FAR too severe. At the very least, I need the upside-down question mark and exclamation points ¿ ¡, as well as the ≤,≥,≠ operators. I mean, you are getting rid of the division sign ÷. How could that ever be controversial as an operator?

This is the first proposal I have seen, where if it goes through, I will actually have to stop using Swift (or find a way not to upgrade)!

Seriously, this proposal would break the vast majority of my code. One of the first things I wrote for Swift was a packrat parser which lets me define rulesets that look like standard PEG using swift operators. I have now written several different projects on top of that. I also have a private extension for ≤,≥,≠ that I use in my projects.

What happened to needing extra justification for breaking changes? We can add them back later, you say. This seems to be breaking things just for the fun of it then…. If you are going to need to break things later to become compatible with something, then break them later. Don’t break my production code now to avoid a 1% chance you might have to break my production code in the future.

[begin quote]

• Operators suffer from low discoverability and difficult readability. They
use symbols, not names. This places a cognitive cost on users with respect
to both recall ("What is the operator that applies the behavior I need?")
and recognition ("What does the operator in this code do?").
• This cost is obviously highest when symbols are not tied to conventional
standards like `∪` for union and `⊇` for superset. `∪` is a standard,
mathematical representation. It’s widely accepted and widely used. Even so,
recognizing `formUnion(with:)` may work better for many coders than
recalling what the `∪` (or, worse, `⊇`) operator does, even when you end up
having to create suites of specialized selectors. As operators become more
self-defined or esoteric, costs rise.

[end quote]

With all due respect, my day job is in the cognitive sciences (I have a master’s degree in Cognitive Psychology) and this is pure bullshit. The entire reason we use symbols is that the opposite is true. Yes, there is temporarily a greater burden on people who are new to a symbol, but once they learn it, it has much faster recall and recognition. That is why we use icons all over the place. It is why mathematicians use symbols. It is why you see all those symbols on signs at the airport.

There are a bunch of symbols in unicode which are hard to tell apart, and those are bad for recognition, and we should deal with that, but this proposal is throwing the baby out with the bathwater, then lighting the baby on fire. Honestly, I would propose we find a way to have Swift see certain classes of characters as identical. Can’t decide which of the thousand + symbols should be the one true + symbol? Have them all map to one of them. That emoji X symbol looks like X, so map it to X.

This proposal is lazy and unreasonable. I think we can all agree that there needs to be thought around confusable symbols… but most of us just aren’t using the confusable symbols. The argument seems to be “Let’s break EVERYTHING now so we don’t have to break it later”, which is pure ridiculousness. Don’t break anything now… and then when you are ready to deal with confusables (which, again, most people aren’t actually using) do it surgically then. You will be breaking a strictly smaller amount of code…


(Matt Whiteside) #2

<snip>

There are a bunch of symbols in unicode which are hard to tell apart, and those are bad for recognition, and we should deal with that, but this proposal is throwing the baby out with the bathwater, then lighting the baby on fire. Honestly, I would propose we find a way to have Swift see certain classes of characters as identical. Can’t decide which of the thousand + symbols should be the one true + symbol? Have them all map to one of them. That emoji X symbol looks like X, so map it to X.

Agreed.

I really like the option of using unicode operators in swift. Removing them would be disappointing. But I do see the problem that there are a lot of redundancies and sources of confusion if there are no restrictions. Aside from the redundancies, some other cases that I find sub-optimal are: 'top-half of integral' ⌠, and 'left parenthesis upper hook’ ⎛ ; these don’t really seem like symbols we want to allow as operators. Perhaps *one* general rule here, is that symbols specifically meant for 2d math expressions aren't good candidates for inclusion, at least at the present. Another difficult one, I think, are the bracket-like glyphs. While these would be useful in certain math and physics related code, it’s not clear at the moment how these could be used in swift, until and unless some kind of ‘bracket overloading’ is made possible.

I’m in favor of what Johnathan Hull has suggested above. I’m also in favor of what some others have suggested, i.e., restricting the allowed operator symbols to some uncontroversial subset, mainly from the unicode ‘math’ category of symbols, and then possibly adding more as needed.

-Matt

···

On Oct 19, 2016, at 19:07, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:


(Xiaodi Wu) #3

That, I think, is where we're headed. Take a look at Jonathan Shapiro's
latest draft and see what you think :slight_smile:

···

On Sat, Oct 22, 2016 at 17:46 Matt Whiteside via swift-evolution < swift-evolution@swift.org> wrote:

On Oct 19, 2016, at 19:07, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote:

<snip>

There are a bunch of symbols in unicode which are hard to tell apart, and
those are bad for recognition, and we should deal with that, but this
proposal is throwing the baby out with the bathwater, then lighting the
baby on fire. Honestly, I would propose we find a way to have Swift see
certain classes of characters as identical. Can’t decide which of the
thousand + symbols should be the one true + symbol? Have them all map to
one of them. That emoji X symbol looks like X, so map it to X.

Agreed.

I really like the option of using unicode operators in swift. Removing
them would be disappointing. But I do see the problem that there are a lot
of redundancies and sources of confusion if there are no restrictions.
Aside from the redundancies, some other cases that I find sub-optimal are:
'top-half of integral' ⌠, and 'left parenthesis upper hook’ ⎛ ; these don’t
really seem like symbols we want to allow as operators. Perhaps
*one* general rule here, is that symbols specifically meant for 2d math
expressions aren't good candidates for inclusion, at least at the present.
Another difficult one, I think, are the bracket-like glyphs. While
these would be useful in certain math and physics related code, it’s not
clear at the moment how these could be used in swift, until and unless some
kind of ‘bracket overloading’ is made possible.

I’m in favor of what Johnathan Hull has suggested above. I’m also in
favor of what some others have suggested, i.e., restricting the allowed
operator symbols to some uncontroversial subset, mainly from the unicode
‘math’ category of symbols, and then possibly adding more as needed.

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