chapel-lang / chapel

a Productive Parallel Programming Language
https://chapel-lang.org
Other
1.78k stars 420 forks source link

Swap operator conflicts with "Spaceship" operator in other languages #8545

Open BryantLam opened 6 years ago

BryantLam commented 6 years ago

Should Chapel change the swap operator currently written <=>, because of a desire to have a three-way comparator ("spaceship") operator ?

Proposals:

As of Chapel 1.16, the ~array~ swap operator is <=>. In other languages, this operator is known as the spaceship operator and functionally serves a different role: three-way comparator and/or consistently overload the LT, LE, GT, GE, EQ, etc. operators.

PHP: https://wiki.php.net/rfc/combined-comparison-operator Ruby: https://ruby-doc.org/core-2.5.0/Comparable.html C++20 Proposal: http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0515r0.pdf

Food for thought. Chapel can continue using this operator for ~array~ swap, but if a need ever arises in the future to add to the language a three-way comparator and/or consistent-comparison overload, the cognitive dissonance will increase for users already accustomed to seeing the spaceship in this use case.

benharsh commented 6 years ago

Note that this operator isn't just for arrays (not that this changes the point of the issue):

var a = "a";
var b = "b";
a <=> b;
writeln("a = ", a);
writeln("b = ", b);

Output:

a = b
b = a
mppf commented 6 years ago

My 2 cents:

The swap operator is used infrequently enough (my opinion, not based on a count or anything) that I'd be comfortable renaming it.

I'm not sure the comparison form of it would be used much more, but I also don't object to it. It's certainly nice to be able to write one comparison overload instead of 6.

I'm used to <=> meaning comparison from Perl, but people seem to immediately ignore Perl as a reasonable language precedent, for better or worse.

bradcray commented 6 years ago

I wasn't familiar with the spaceship operator, but understand its appeal. I'd like to support the spaceship operator but would like to continue to support swap assignment as well (ideally without breaking backwards compatibility).

I've been brainstorming about what either of them could be replaced with and this led me to think that <==> could be an alternative spaceship operator in Chapel. Main downside: It differs from what Ruby, PHP, and C++20 use. Main upside: The use of == looks more like comparison; it embeds more of the comparisons into its name (since <=> fails to embed == :) ). Another note is that if a PHP or Ruby user wrote a <=> overload thinking it was the comparator definition, this is something the compiler could catch (since swap assignment returns nothing and the comparison case returns an integer), error about, and point them in the right direction in doing so.

If instead we were to change the swap operator, the main idea I've come up with is: >=< which I feel OK about other than the fact that it's a change (and a bit less intuitive... I've given lots of talks using the swap operator, and people usually snap to what it is without being told).

BryantLam commented 6 years ago

Note that I'm not asking Chapel to necessarily implement the spaceship operator (yet); merely recognize that it exists and conflicts with the current swap operator.

That said, I'd personally prefer renaming the swap operator to something else: <->, <~> (I like this one. It's easy to type.), or even just a swap b. I agree with @mppf that I don't think this operator is used often enough that renaming it now will significantly break a large percentage of code.

Edit: I thought <~> looked familiar. It used as the I/O read/write operator.

mppf commented 5 years ago

If we move to a single comparison operator, what do types that only support some of the comparisons do? For example currently class instances in Chapel support == and != but not <. The C++ proposal (as an example) encodes this information in the return type of <=>.

mppf commented 5 years ago

One strategy would be to just use regular operator overloads in the event some comparisons are not available. Another question inspired by the C++ effort is - should the <==> overload indicate if it's a partial or total ordering?