Re: Interval Comparisons

On 05/06/2024 02:30, Lawrence D'Oliveiro wrote:

On Wed, 5 Jun 2024 00:22:36 +0100, bart wrote:
 

On 05/06/2024 00:12, Lawrence D'Oliveiro wrote:
>

On Tue, 4 Jun 2024 11:41:54 -0000 (UTC), Blue-Maned_Hawk wrote:
>

i think that we need not worsen the matter with new ternary operators.

>
These are not ternary operators.

>
So what are they?

 A special case in the syntax rules for the comparison operators
<https://docs.python.org/3/reference/expressions.html#comparisons>.
 

I've implemented them several times, and found they really need to be
treated as a special kind of n-ary opterator.

 Remember, Python allows users to define custom overloads for the standard
operators. For comparisons, these functions always take two operands, and
the compiler takes care of invoking them correctly to handle interval
comparisons.

Well, for these 3 lines in my scripting language:
   if a = b then end             # universal
   if a = b < c then end         # chained (like Python, unlike C)
   if (a = b) < c then end       # emulate C behaviour
These are the ASTs produced (2: is the empty True branch; 3: would be for the 'else' branch, not present here):
- 1 if:
- - 1 eq:
- - - 1 name: a
- - - 2 name: b
- - 2 block:
- 1 if:
- - 1 cmpchain: eq lt
- - - 1 name: a
- - - 1 name: b
- - - 1 name: c
- - 2 block:
- 1 if:
- - 1 lt:
- - - 1 eq:
- - - - 1 name: a
- - - - 2 name: b
- - - 2 name: c
- - 2 block:
Notice the middle one is one linear group with N operands and N-1 comparisons.
No operator overloads are allowed, but if they were, it would still work, but a comparison operator would be required to return True or False from its two operands. It would be unwise for it to return a string for example.