Chained comparison operators

[Rangi42]

Python-style, < <= > >= == != would be chainable instead of left-associative.

To do, think about how practical this would be to parse.

[Rangi42]

Note that when/if we implement lazy evaluation, it's still possible with chained comparisons:

>>> 1 > 2 > 3 / 0
False
>>> 1 < 2 < 3 / 0
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    1 < 2 < 3 / 0
ZeroDivisionError: division by zero

[Rangi42]

Instead of this (entirely relying on %left/%right/%precedence):

relocexpr_no_str:
	NUMBER { $$ = $1; }
	| "!" relocexpr %prec NEG { $$ = !$2; }
	| relocexpr "+" relocexpr { $$ = $1 + $3; }
	| relocexpr "*" relocexpr { $$ = $1 * $3; }
	| relocexpr "<" relocexpr { $$ = $1 < $3; }
	| relocexpr ">" relocexpr { $$ = $1 > $3; }
	| relocexpr "||" relocexpr { $$ = $1 || $3; }
	| relocexpr "&&" relocexpr { $$ = $1 && $3; }
	| ...etc
	| "(" relocexpr ")" { $$ = $2; }
;

relocexpr:
	relocexpr_no_str { ... }
	| string_literal { ... }
	| scoped_sym { ... }
;

We would do something like this (still mostly relying on them, but with the "comparisons" precedence level manually split out between Boolean AND/OR and everything else):

comparand:
	NUMBER { $$ = $1; }
	| "!" relocexpr %prec NEG { $$ = !$2; }
	| relocexpr "+" relocexpr { $$ = $1 + $3; }
	| relocexpr "*" relocexpr { $$ = $1 * $3; }
	| ...etc
	| "(" relocexpr ")" { $$ = $2; }
;

comparison:
	comparand {
		$$.value = $1;
		$$.prev = $1;
	}
	| comparison "<" comparand {
		$$.value = $$.value && $$.prev < $3;
		$$.prev = $3;
	}
	| comparison ">" comparand {
		$$.value = $$.value && $$.prev > $3;
		$$.prev = $3;
	}
	| ...etc
;

relocexpr_no_str:
	comparison { $$ = $1.value; }
	| comparison "||" comparison { $$ = $1.value || $2.value; }
	| comparison "&&" comparison { $$ = $1.value && $2.value; }
;

relocexpr:
	relocexpr_no_str { ... }
	| string_literal { ... }
	| scoped_sym { ... }
;

[Rangi42]

Feedback so far is fairly positive: "very useful and comprehensible shorthand" [1]; "yes, it should absolutely do [chained comparison], you should be forced to put out explicit parens" [2]; "if it wasn't a breaking change, it could be useful" [3].

[Rangi42]

Also git grep -nP ' [<>=]=? [^&,]+ [<>=]=? ' test doesn't even turn up any artificial test cases that would break. All the results are e.g. comments like ; -2 == (1 << 4) - 2 == -2 mod (1 << 4), or strings like "{#09x:v} = {#012o:v} = {#033b:v} = {u:v}U = {+d:v} = {+.16f:v}", or unchained comparisons like 1 == 1 || 1 == 2.

[Rangi42]

Chaining comparison operators is supported in Python, Raku (Perl 6), Julia, Mathematica, Icon (Wikipedia: "blends the short but conceptually dense code of SNOBOL-like languages with the more familiar syntax of ALGOL-inspired languages like C or Pascal ... a major inspiration for the Python language"), and Miranda (Wikipedia: "first released in 1985 as a fast interpreter in C for Unix-flavour operating systems ... had a strong influence on the later Haskell language"). Python Raku, Julia, and Icon support mixing operators like 3 > 1 < 2; Mathematica does not, although it still supports mixing </<= and >/>=.

There were proposals for this in C++ and C#; although they weren't accepted, they both have interesting discussion of design decisions involved with this feature.

Note that the C# proposal was against mixing directions ("a > b < c and a < b > c should be illegal and throw a compile error") but pointed out that == is compatible with either direction ("a <= b < c == d < e ... still shorter and more readable than a <= b && b < c && c == d && d < e and less error prone").

[Rangi42]

I was way too optimistic about how easy this would be to parse. Postponing to 2.0, which currently uses a Pratt parser (1, 2) and might have an easier time of it (no shift/reduce conflicts).