I've got loads of other posts in this ng to respond to but I came across
something last night that I thought you might find interesting.

The issue is whether a language should support chained comparisons such
as where

A < B < C

means that B is between A and C? Or should a programmer have to write

A < B && B < C

?

I like the visual simplicity of the first form but it doesn't look so
intuitive with a mix of relational operators such as in

A < B > C

What does that mean?!

For programming, what do you guys prefer to see in a language? Would you
rather have each relation yield false/true (so that A < B in the above
yields a boolean) or to allow the above kind of chaining where a meaning
is attributed to a succession of such operators?

If the latter, what rules should govern how successive relational
operators are applied?

--
James Harris

On 05/09/2021 11:50, James Harris wrote:
> I've got loads of other posts in this ng to respond to but I came across
> something last night that I thought you might find interesting.
>
> The issue is whether a language should support chained comparisons such
> as where
>
>   A < B < C
>
> means that B is between A and C? Or should a programmer have to write
>
>   A < B && B < C
>
> ?
>
> I like the visual simplicity of the first form but it doesn't look so
> intuitive with a mix of relational operators such as in
>
>   A < B > C
>
> What does that mean?!
>
> For programming, what do you guys prefer to see in a language? Would you
> rather have each relation yield false/true (so that A < B in the above
> yields a boolean) or to allow the above kind of chaining where a meaning
> is attributed to a succession of such operators?
>
> If the latter, what rules should govern how successive relational
> operators are applied?

I support such operators (althought it might be limited to 4 operators).
Something like:

A op1 B op2 C op3 D

is approximately the same as:

(A op1 B) and (B op2 C) and (C op3) D

except that the middle terms should be evaluated once, not twice.

(I thought I was doing them once, but it seems to have lapsed back to
double evaluation; I'll have to check it out.

Double evaluaton is hard to avoid if doing this by transforming the AST
into that second version. But I now use a special AST form where middle
terms occur only once, so there's no excuse).

As for use-case, I mostly use it with equals:

if A = B = C then

I did use to do:

if A <= B <= C then

but I now tend to have a dedicated op for that which is:

if A in B..C then

So chained comparisons /could/ be restricted to equals only. Except some
will want to do A < B <= C and so on.

In any case, any combinations will be well-defined. Your last example
means A < B and B > C, and will be true for A, B, C values of 5, 20, 10
for example.

On 05/09/2021 11:50, James Harris wrote:
> I've got loads of other posts in this ng to respond to but I came across
> something last night that I thought you might find interesting.
>
> The issue is whether a language should support chained comparisons such as where
>
>   A < B < C

I think in most languages operators of the same precedence would associate to
the left. So that would mean whatever is meant by

(A < B) < C

which in most languages would be ill-formed (unless you had overloaded '<' with
some suitable meaning).
>
> means that B is between A and C? Or should a programmer have to write
>
>   A < B && B < C

Yes

>
> ?
>
> I like the visual simplicity of the first form but it doesn't look so intuitive
> with a mix of relational operators such as in
>
>   A < B > C
>
> What does that mean?!

Nothing unless you had defined some meaning. For sure you could define a
language which allowed such constructs, but it would stick out as a special case
like a sore thumb.

Note that

A + B + C
has a defined meaning, but
A + C + B
might be different (one or the other might overflow).

> applied?
>
>

--
Charles H. Lindsey ---------At my New Home, still doing my own thing------
Tel: +44 161 488 1845 Web: https://www.clerew.man.ac.uk
Email: chl@clerew.man.ac.uk Snail-mail: Apt 40, SK8 5BF, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

On 05/09/2021 15:36, Charles Lindsey wrote:
> On 05/09/2021 11:50, James Harris wrote:
>> I've got loads of other posts in this ng to respond to but I came
>> across something last night that I thought you might find interesting.
>>
>> The issue is whether a language should support chained comparisons
>> such as where
>>
>>    A < B < C
>
> I think in most languages operators of the same precedence would
> associate to the left. So that would mean whatever is meant by
>
> (A < B) < C
>
> which in most languages would be ill-formed (unless you had overloaded
> '<' with some suitable meaning).
>>
>> means that B is between A and C? Or should a programmer have to write
>>
>>    A < B && B < C
>
> Yes
>
>>
>> ?
>>
>> I like the visual simplicity of the first form but it doesn't look so
>> intuitive with a mix of relational operators such as in
>>
>>    A < B > C
>>
>> What does that mean?!
>
> Nothing unless you had defined some meaning. For sure you could define a
> language which allowed such constructs, but it would stick out as a
> special case like a sore thumb.

Yes, it a little different. In my case it's more like an N-ary operator,
so that this fragment:

real x, y, z
x < y < z

Generates this AST (one composite operator and 3 operands):

i64------- 1 cmpchain: <op_lt_r64 op_lt_r64>
r64------- - 1 name: x
r64------- - 1 name: y
r64------- - 1 name: z

To do the same thing without the feature, you'd need to write:

x < y and y < z

with this more elaborate AST:

i64------- - 1 andl: <andl_i64>
i64------- - - 1 cmp: <lt_r64>
r64------- - - - 1 name: x
r64------- - - - 2 name: y
i64------- - - 2 cmp: <lt_r64>
r64------- - - - 1 name: y
r64------- - - - 2 name: z

With the problem that y (if an expression) could have side-effects that
may be executed twice, but you'd want to avoid evaluating it twice
anyway, so extra effort.

On 05/09/2021 15:36, Charles Lindsey wrote:
> On 05/09/2021 11:50, James Harris wrote:
>> I've got loads of other posts in this ng to respond to but I came
>> across something last night that I thought you might find interesting.
>>
>> The issue is whether a language should support chained comparisons
>> such as where
>>
>>    A < B < C
>
> I think in most languages operators of the same precedence would
> associate to the left. So that would mean whatever is meant by
>
> (A < B) < C
>
> which in most languages would be ill-formed (unless you had overloaded
> '<' with some suitable meaning).

Either overloaded 'number op bool' or decided that comparison operators
result in an integer (as C does) so that it can be the input to another
comparison against a number.

>>
>> means that B is between A and C? Or should a programmer have to write
>>
>>    A < B && B < C
>
> Yes

Noted. Given that viewpoint what do you make of

https://youtu.be/M3GAJ1AIIlA

?

....

> Note that
>
> A + B + C
> has a defined meaning, but
> A + C + B
> might be different (one or the other might overflow).

Good point. Language expressions are not quite the same as mathematical
ones.

--
James Harris

On 05/09/2021 12:50, James Harris wrote:
> I've got loads of other posts in this ng to respond to but I came across
> something last night that I thought you might find interesting.
>
> The issue is whether a language should support chained comparisons such
> as where
>
>   A < B < C
>
> means that B is between A and C? Or should a programmer have to write
>
>   A < B && B < C
>
> ?
>

Ask yourself if the need to check that a value is within a range is
common enough that you need a special syntax to handle it. I'd say no,
but there is always a balance to be found and it varies from language to
language. I am not a fan of having lots of special syntaxes, or
complicated operators - whether they are done using symbols or vast
numbers of keywords.

My vote would be to make relational operators return a "boolean", and to
make operations between booleans and other types a syntax error or
constraint error, and to disallow relational operators for booleans.
Then "A < B < C" is a compile-time error. It is not particularly hard
to write "A < B && B < C" when you need it. Put more focus on making it
hard to write incorrect or unclear code.

On 05/09/2021 12:27, Bart wrote:
> On 05/09/2021 11:50, James Harris wrote:

....

>>    A < B < C

....

>> For programming, what do you guys prefer to see in a language? Would
>> you rather have each relation yield false/true (so that A < B in the
>> above yields a boolean) or to allow the above kind of chaining where a
>> meaning is attributed to a succession of such operators?
>>
>> If the latter, what rules should govern how successive relational
>> operators are applied?
>
>
> I support such operators (althought it might be limited to 4 operators).
> Something like:
>
>   A op1 B op2 C op3 D
>
> is approximately the same as:
>
>   (A op1 B) and (B op2 C) and (C op3) D
>
> except that the middle terms should be evaluated once, not twice.

Until seeing https://youtu.be/M3GAJ1AIIlA (which is the same link I
posted in reply to Charles) I never realised that there was a simple and
logical way to interpret operator sequences but it appears I am well
behind the curve. You do that, and so did BCPL in 1967!

But there's a question of relative precedences.

I take it that aside from single evaluation you treat

A op1 B op2 C

essentially as

(A op1 B) and (B op2 C)

but how did you choose to have that interact with higher and lower
precedences of surrounding operators? Do you treat chained comparisons
as syntactic sugar or as compound expressions in their own right?

My booleans operators (such as 'and' and 'not') have lower precedence
than comparisons (but with 'not' having higher precedence than 'and')
and my arithmetic operators have higher precedence.

In case that's confusing, for these few operators I have the following
order (higher to lower).

Arithmetic operators including +
Comparisons including <
Booleans including 'not' and 'and'

Therefore,

not a < b + 1 and b + 1 < c

would evaluate the (b + 1)s first, as in

B = (b + 1)

It would then apply 'not' before 'and' as in

(not (a < B)) and (B < c)

but if I were to implement operator chaining I think it would be better
for the 'not' in

not a < B < c

to apply to the entire comparison

not (a < B < c)

In a sense, the 'and' which is part of comparison chaining would have
the same precedence as the comparison operators rather than the
precedence of the real 'and' operator.

If you are still with me(!), what did you choose?

....

> In any case, any combinations will be well-defined. Your last example
> means A < B and B > C, and will be true for A, B, C values of 5, 20, 10
> for example.

Now I know what the expression means I find it surprisingly easy to read
- just adding "and" between parts and knowing that all parts must be
true for the composite comparison to be true makes any uses of it easy
to understand.

--
James Harris

On 06/09/2021 10:55, David Brown wrote:
> On 05/09/2021 12:50, James Harris wrote:
>> I've got loads of other posts in this ng to respond to but I came across
>> something last night that I thought you might find interesting.
>>
>> The issue is whether a language should support chained comparisons such
>> as where
>>
>>   A < B < C
>>
>> means that B is between A and C? Or should a programmer have to write
>>
>>   A < B && B < C
>>
>> ?
>>

[OK, this is a /fourth/ reply to you within half an hour. You should
stop saying things I disagree with!]

> Ask yourself if the need to check that a value is within a range is
> common enough that you need a special syntax to handle it.

Yes, it is, in my code anyway.

I used to use A <= B <= C for that, until that was replaced by A in B..C:

elsif c='1' and lxsptr^ in '0'..'6' and ...

Some older code:

return int32.min <= x <= int32.max

(However a more common use of 'in' is to compare against several values:
'A in [B, C, D]')

> I'd say no,
> but there is always a balance to be found and it varies from language to
> language. I am not a fan of having lots of special syntaxes, or
> complicated operators - whether they are done using symbols or vast
> numbers of keywords.

In C-style, the example above would be:

else if (c=='1' && *lxsptr>='0' && *lxsptr<='6' && ...)

> My vote would be to make relational operators return a "boolean",

They do. Except that A=B=C is not two operators, but treated as a single
operator: (A=B=C) returns a boolean.

> It is not particularly hard
> to write "A < B && B < C" when you need it.

* B has to be written twice

* It's not always a simple expression, so you need to ensure both are
actually identical

* The reader needs to double check that it /is/ the same expression

* The compiler needs to do extra work to avoid evaluating it twice

* But if it has side-effects, the compiler is obliged to evaluate twice

On 06/09/2021 12:41, Bart wrote:
> On 06/09/2021 10:55, David Brown wrote:
>> On 05/09/2021 12:50, James Harris wrote:
>>> I've got loads of other posts in this ng to respond to but I came across
>>> something last night that I thought you might find interesting.
>>>
>>> The issue is whether a language should support chained comparisons such
>>> as where
>>>
>>>    A < B < C
>>>
>>> means that B is between A and C? Or should a programmer have to write
>>>
>>>    A < B && B < C
>>>
>>> ?
>>>
>
> [OK, this is a /fourth/ reply to you within half an hour. You should
> stop saying things I disagree with!]
>

I've been interspersing with a few agreements...

>
>> Ask yourself if the need to check that a value is within a range is
>> common enough that you need a special syntax to handle it.
>
> Yes, it is, in my code anyway.
>
> I used to use A <= B <= C for that, until that was replaced by A in B..C:

If a language supports a concept of ranges, represented by "b .. c" (or
similar syntax), then "a in b .. c" is a good way to handle such tests.
I would not invent such a syntax purely for such tests, but if it is
used for array slices, for-loops, etc., then you have a good feature.

(Since I may have accidentally complemented you for a language feature,
I need to add balance - don't you have a space key on your keyboard?
Why don't you use it when writing code?)

>
>     elsif c='1' and lxsptr^ in '0'..'6' and ...
>
> Some older code:
>
>     return int32.min <= x <= int32.max
>
> (However a more common use of 'in' is to compare against several values:
> 'A in [B, C, D]')
>
>> I'd say no,
>> but there is always a balance to be found and it varies from language to
>> language.  I am not a fan of having lots of special syntaxes, or
>> complicated operators - whether they are done using symbols or vast
>> numbers of keywords.
>
> In C-style, the example above would be:
>
>     else if (c=='1' && *lxsptr>='0' && *lxsptr<='6' && ...)
>
>
>> My vote would be to make relational operators return a "boolean",
>
> They do. Except that A=B=C is not two operators, but treated as a single
> operator: (A=B=C) returns a boolean.
>
>>  It is not particularly hard
>> to write "A < B && B < C" when you need it.
>
> * B has to be written twice
>
> * It's not always a simple expression, so you need to ensure both are
> actually identical
>
> * The reader needs to double check that it /is/ the same expression
>
> * The compiler needs to do extra work to avoid evaluating it twice
>
> * But if it has side-effects, the compiler is obliged to evaluate twice
>

If B is complicated, you can always use a local variable - split things
up to make them clear. (Of course, you want a language that has proper
scoped local variables for that - but you'd want that anyway.)

On 06/09/2021 11:28, James Harris wrote:
> On 05/09/2021 12:27, Bart wrote:

> I take it that aside from single evaluation you treat
>
>   A op1 B op2 C
>
> essentially as
>
>   (A op1 B) and (B op2 C)

> but how did you choose to have that interact with higher and lower
> precedences of surrounding operators?

Exactly the same as a single comparison operator. All comparisons are
the same precedence (see below), so:

A + B = C = D + E is (A+B) = C = (D+E)

A and B = C = D and E is A and (B=C=D) and E

> Do you treat chained comparisons
> as syntactic sugar or as compound expressions in their own right?

I used to transform them into explicit AND expressions, but that wasn't
satisfactory. Now chained comparisons form a single AST node (see my
reply to Charles).

> My booleans operators (such as 'and' and 'not') have lower precedence
> than comparisons (but with 'not' having higher precedence than 'and')
> and my arithmetic operators have higher precedence.
>
> In case that's confusing, for these few operators I have the following
> order (higher to lower).
>
>   Arithmetic operators including +
>   Comparisons including <
>   Booleans including 'not' and 'and'

You have the wrong precedence for 'not'. As a unary operator, it should
work like C's - (negate), !, ~.

> Therefore,
>
>   not a < b + 1 and b + 1 < c
>
> would evaluate the (b + 1)s first, as in
>
>   B = (b + 1)
>
> It would then apply 'not' before 'and' as in
>
>   (not (a < B)) and (B < c)
>
> but if I were to implement operator chaining I think it would be better
> for the 'not' in
>
>   not a < B < c
>
> to apply to the entire comparison
>
>   not (a < B < c)

As written here that's fine. But I'd have a problem with making a
special case for unary 'not':

not A < B means not (A < B)? (I assume it applies to single >)
-A < B means (-A) < B

For the first, just use parentheses. (I also use:

unless A < B ...

for the reverse logic)

> In a sense, the 'and' which is part of comparison chaining would have
> the same precedence as the comparison operators rather than the
> precedence of the real 'and' operator.
>
> If you are still with me(!), what did you choose?

These are my precedence levels:

8 ** # highest

7 * / rem << >>
6 + - iand ior ixor
5 ..
4 = <> < <= >= > in notin
3 and
2 or

1 := # lowest

And, Or are lower precedence than comparisons.

Unary op are always applied first (but multiple unary ops on either side
of a term - prefix and postfix - have their own rules).

On 2021-09-06 13:24, David Brown wrote:

> If a language supports a concept of ranges, represented by "b .. c" (or
> similar syntax), then "a in b .. c" is a good way to handle such tests.
> I would not invent such a syntax purely for such tests, but if it is
> used for array slices, for-loops, etc., then you have a good feature.

Yes, and this is another challenge for the type system, unless ranges
are built-in (e.g. in Ada).

In a more powerful type system "in", ".." could be operations as any
other. The range would be a first-class type.

Further generalization. The mathematical term for range is an indicator
set. A general case indicator set can be non-contiguous, e.g. a number
of ranges. Others examples are a set of indices extracting a column of a
matrix, a submatrix, a diagonal of a matrix etc.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 06/09/2021 12:25, Bart wrote:
> On 06/09/2021 11:28, James Harris wrote:
>> On 05/09/2021 12:27, Bart wrote:

....

>> Do you treat chained comparisons as syntactic sugar or as compound
>> expressions in their own right?
>
> I used to transform them into explicit AND expressions, but that wasn't
> satisfactory. Now chained comparisons form a single AST node (see my
> reply to Charles).

IIRC in your reply to Charles your node relied on the programmer using
the same operator as in the < of

A < B < C

whereas proper chaining requires support for different operators such as

A < B <= C

If one is going to support chaining then AISI that expression should
also be parsed to be a node.

>
>
>
>
>> My booleans operators (such as 'and' and 'not') have lower precedence
>> than comparisons (but with 'not' having higher precedence than 'and')
>> and my arithmetic operators have higher precedence.
>>
>> In case that's confusing, for these few operators I have the following
>> order (higher to lower).
>>
>>    Arithmetic operators including +
>>    Comparisons including <
>>    Booleans including 'not' and 'and'
>
> You have the wrong precedence for 'not'. As a unary operator, it should
> work like C's - (negate), !, ~.

I am not copying C!

I could have chosen to do so, of course. But some of it's operator
precedence levels are in the wrong order. Even DMR acknowledged that.

If one is not going to copy C's why decide to copy any of it? If some
precedences are going to be different then why not just do whatever's best?

....

>> but if I were to implement operator chaining I think it would be
>> better for the 'not' in
>>
>>    not a < B < c
>>
>> to apply to the entire comparison
>>
>>    not (a < B < c)
>
> As written here that's fine. But I'd have a problem with making a
> special case for unary 'not':
>
>    not A < B       means not (A < B)? (I assume it applies to single >)
>    -A < B          means (-A) < B

Why are you equating a boolean with an arithmetic operator? What
connection do you see between them?

;-)

>
> For the first, just use parentheses. (I also use:
>
>    unless A < B ...
>
> for the reverse logic)
>
>
>> In a sense, the 'and' which is part of comparison chaining would have
>> the same precedence as the comparison operators rather than the
>> precedence of the real 'and' operator.
>>
>> If you are still with me(!), what did you choose?
>
> These are my precedence levels:
>
>   8   **                             # highest
>
>   7   * / rem << >>
>   6   + - iand ior ixor
>   5   ..
>   4   = <> < <= >= > in notin
>   3   and
>   2   or
>
>   1   :=                             # lowest

I have a different and arguably simpler order. Of those you mention,
highest to lowest I have

* bitwise ops
* arithmetic ops
* comparison ops
* boolean ops
* assignment ops

So

not A gt B

means

not (A gt B)

If you think about it some more I believe you'll agree that it makes
sense and will immediately change your compiler and all your source code
to suit. ;-)

I am not saying I would not change what I have so far but I've put a lot
of thought into the precedence table. Keeping the operators in logical
groups or 'families' makes the overall order a great deal easier to
remember. For example, **all** the boolean ops are applied after the
comparison ops.

Within each family the operators are in familiar orders, e.g.
multiplication comes before addition, 'and' comes before 'or', etc.

>
> And, Or are lower precedence than comparisons.
>
> Unary op are always applied first (but multiple unary ops on either side
> of a term - prefix and postfix - have their own rules).

Having "their own rules" sounds as though it could be confusing.

:-(

--
James Harris

On 06/09/2021 14:02, Dmitry A. Kazakov wrote:
> On 2021-09-06 13:24, David Brown wrote:
>
>> If a language supports a concept of ranges, represented by "b .. c" (or
>> similar syntax), then "a in b .. c" is a good way to handle such tests.
>>   I would not invent such a syntax purely for such tests, but if it is
>> used for array slices, for-loops, etc., then you have a good feature.
>
> Yes, and this is another challenge for the type system, unless ranges
> are built-in (e.g. in Ada).
>
> In a more powerful type system "in", ".." could be operations as any
> other. The range would be a first-class type.
>
> Further generalization. The mathematical term for range is an indicator
> set. A general case indicator set can be non-contiguous, e.g. a number
> of ranges. Others examples are a set of indices extracting a column of a
> matrix, a submatrix, a diagonal of a matrix etc.
>

I think you'd want to avoid that kind of generalisation, at least at the
language level. Having an "in" operator that could be used with
different types would be all you need. The language could support
common cases that are simple to implement, such as Pascal-like sets, or
a range made as a pair of two types that support relational operators.
But support for more general sets, collections of ranges, etc., should
be left to classes.

On 06/09/2021 10:55, David Brown wrote:
> On 05/09/2021 12:50, James Harris wrote:
>> I've got loads of other posts in this ng to respond to but I came across
>> something last night that I thought you might find interesting.
>>
>> The issue is whether a language should support chained comparisons such
>> as where
>>
>>   A < B < C
>>
>> means that B is between A and C? Or should a programmer have to write
>>
>>   A < B && B < C
>>
>> ?
>>
>
> Ask yourself if the need to check that a value is within a range is
> common enough that you need a special syntax to handle it.

I don't see this as that special a syntax but (at least, potentially) an
expression form which is widely useful and easy to understand. That is,
of course, once one knows the rules(!) but the rules look as though they
could be easy to grasp: For a series of comparison ops in a phrase such as

A op B op C op D

the ops would apply left to right, with inner expressions being
evaluated as they were encountered, and result in True if all
subcomponents were true; if any were found to be false then the rest of
the phrase would not be evaluated. Maybe I'm missing something but that
seems remarkably simple.

> I'd say no,
> but there is always a balance to be found and it varies from language to
> language. I am not a fan of having lots of special syntaxes, or
> complicated operators - whether they are done using symbols or vast
> numbers of keywords.
>
> My vote would be to make relational operators return a "boolean", and to
> make operations between booleans and other types a syntax error or
> constraint error, and to disallow relational operators for booleans.
> Then "A < B < C" is a compile-time error. It is not particularly hard
> to write "A < B && B < C" when you need it. Put more focus on making it
> hard to write incorrect or unclear code.
>

Noted.

One thing in favour of the chained operators (other than their
simplicity once one knows the rules) is single evaluation. In

A < sub(B) <= C

would evaluate sub(B) once.

I am not decided yet on whether to support this but I do note that it
was present in BCPL in some form in 1967 so it's not a new concept and I
find it surprisingly easy to read - just say "and" between parts! :-)

--
James Harris

On 2021-09-06 14:25, David Brown wrote:
> On 06/09/2021 14:02, Dmitry A. Kazakov wrote:
>> On 2021-09-06 13:24, David Brown wrote:
>>
>>> If a language supports a concept of ranges, represented by "b .. c" (or
>>> similar syntax), then "a in b .. c" is a good way to handle such tests.
>>>   I would not invent such a syntax purely for such tests, but if it is
>>> used for array slices, for-loops, etc., then you have a good feature.
>>
>> Yes, and this is another challenge for the type system, unless ranges
>> are built-in (e.g. in Ada).
>>
>> In a more powerful type system "in", ".." could be operations as any
>> other. The range would be a first-class type.
>>
>> Further generalization. The mathematical term for range is an indicator
>> set. A general case indicator set can be non-contiguous, e.g. a number
>> of ranges. Others examples are a set of indices extracting a column of a
>> matrix, a submatrix, a diagonal of a matrix etc.
>
> I think you'd want to avoid that kind of generalisation, at least at the
> language level. Having an "in" operator that could be used with
> different types would be all you need. The language could support
> common cases that are simple to implement, such as Pascal-like sets, or
> a range made as a pair of two types that support relational operators.
> But support for more general sets, collections of ranges, etc., should
> be left to classes.

But given a user type you want to be able to have arrays, vectors
matrices indexed by the type. You want standard loops working with it
etc. The usual OOPL method is to manually create a dozen of helper
classes that producing a total mess and still no support of slices,
submatrices etc. I would like some integrated mechanics for this stuff.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 06/09/2021 13:20, James Harris wrote:
> On 06/09/2021 12:25, Bart wrote:
>> On 06/09/2021 11:28, James Harris wrote:
>>> On 05/09/2021 12:27, Bart wrote:
>
> ...
>
>>> Do you treat chained comparisons as syntactic sugar or as compound
>>> expressions in their own right?
>>
>> I used to transform them into explicit AND expressions, but that
>> wasn't satisfactory. Now chained comparisons form a single AST node
>> (see my reply to Charles).
>
> IIRC in your reply to Charles your node relied on the programmer using
> the same operator as in the < of
>
>   A < B < C
>
> whereas proper chaining requires support for different operators such as
>
>   A < B <= C
>
> If one is going to support chaining then AISI that expression should
> also be parsed to be a node.

That's just because that same example was used in previous posts.

For parsing purposes, then = <> < <= >= > are all treated the same.

>>> In case that's confusing, for these few operators I have the
>>> following order (higher to lower).
>>>
>>>    Arithmetic operators including +
>>>    Comparisons including <
>>>    Booleans including 'not' and 'and'
>>
>> You have the wrong precedence for 'not'. As a unary operator, it
>> should work like C's - (negate), !, ~.
>
> I am not copying C!

I used C because that's widely known. But unary ops, in pretty much
every language I've tried, always bind more tightly than binary ops. So
they don't have meaningful precedence.

(There might be the odd exception such as -A**B which in maths means
-(A**B) not (-A)**B. Actually maths would be a good model for this:

sin x + y

means (sin(x)) + y not sin(x+y).)

>

>>>    not (a < B < c)
>>
>> As written here that's fine. But I'd have a problem with making a
>> special case for unary 'not':
>>
>>     not A < B       means not (A < B)? (I assume it applies to single >)
>>     -A < B          means (-A) < B
>
> Why are you equating a boolean with an arithmetic operator? What
> connection do you see between them?

Both not and - (negate) are unary ops, and should be parsed the same
way, regardless of what types they typically take.

>
>   ;-)
>
>
>
>>
>> For the first, just use parentheses. (I also use:
>>
>>     unless A < B ...
>>
>> for the reverse logic)
>>
>>
>>> In a sense, the 'and' which is part of comparison chaining would have
>>> the same precedence as the comparison operators rather than the
>>> precedence of the real 'and' operator.
>>>
>>> If you are still with me(!), what did you choose?
>>
>> These are my precedence levels:
>>
>>    8   **                             # highest
>>
>>    7   * / rem << >>
>>    6   + - iand ior ixor
>>    5   ..
>>    4   = <> < <= >= > in notin
>>    3   and
>>    2   or
>>
>>    1   :=                             # lowest
>
> I have a different and arguably simpler order. Of those you mention,
> highest to lowest I have
>
>   * bitwise ops
>   * arithmetic ops
>   * comparison ops
>   * boolean ops
>   * assignment ops

That's the same as mine except that you treat bitwise ops (and or xor
shifts) as higher than anything else, and in the same group?

But I don't believe this is the complete set of precedence levels,
unless "+" has the same precedence as "*" so that:

a + b * c

means (a+b) * c, contrary to school arithmetic rules.

> So
>
>   not A gt B
>
> means
>
>   not (A gt B)
>
> If you think about it some more I believe you'll agree that it makes
> sense and will immediately change your compiler and all your source code
> to suit. ;-)

This is interesting, because I used to write expressions like this:

if not (A in B)

as without the parentheses, it would be (not A ) in B. But rather than
introduce bizarre rules for 'not', contrary to every other language so
it would cause confusion, I instead allowed:

if A not in B

However this doesn't work well or comparison ops, or with a chain of
such ops.

The only way your proposal can make sense, is for either a single
comparison or chain of comparisons to bind so tightly that it forms a
single term.

So syntactically, A<B<C is treated like A.B.C.

That means dispensing with normal precedence rules for comparison, which
would have consequences:

if N + 1 <= Limit then ++N ...

would end up being parsed as :

if N + (1 <= Limit) then ++N ...

> I am not saying I would not change what I have so far but I've put a lot
> of thought into the precedence table. Keeping the operators in logical
> groups or 'families' makes the overall order a great deal easier to
> remember. For example, **all** the boolean ops are applied after the
> comparison ops.
>
> Within each family the operators are in familiar orders, e.g.
> multiplication comes before addition, 'and' comes before 'or', etc.

See above.

>
>
>>
>> And, Or are lower precedence than comparisons.
>>
>> Unary op are always applied first (but multiple unary ops on either
>> side of a term - prefix and postfix - have their own rules).
>
> Having "their own rules" sounds as though it could be confusing.
>
> :-(

This is to be in line with other languages. It means that this term:

op1 op2 X op3 op4

is parsed as:

op1(op2(op4((op3 X))))

In practice it works intuitively; you mustn't over-think it! So:

-P^ # ^ is a deref op

means -(P^). (^ is really syntax, not an operator, but it follows the
same rules.)

Since P here needs to be a pointer, negating it first wouldn't be useful.

On 06/09/2021 13:02, Dmitry A. Kazakov wrote:
> On 2021-09-06 13:24, David Brown wrote:
>
>> If a language supports a concept of ranges, represented by "b .. c" (or
>> similar syntax), then "a in b .. c" is a good way to handle such tests.
>>   I would not invent such a syntax purely for such tests, but if it is
>> used for array slices, for-loops, etc., then you have a good feature.
>
> Yes, and this is another challenge for the type system, unless ranges
> are built-in (e.g. in Ada).
>
> In a more powerful type system "in", ".." could be operations as any
> other. The range would be a first-class type.

I guess my dynamic language has a powerful type system then!

".." is not quite an operator, but a constructor which takes two
integers and yields a range type.

And a range is a proper first class type:

a := 10..20
println a.type # 'range'
println a.lwb # 10
println a.upb # 20
println a.len # 11
println a.bounds # 10..20
println a[10] # 10 (index must be 10..20)
println a.isrange # 1 (true)
println 13 in a # 1 (true)

b := new(list, a)
println b.bounds # 10..20

for i in a do
println sqr i # 100 to 400
od

In my static language however, then ranges are mostly syntax.

On 06/09/2021 14:46, Bart wrote:
> On 06/09/2021 13:20, James Harris wrote:
>> On 06/09/2021 12:25, Bart wrote:
>>> On 06/09/2021 11:28, James Harris wrote:

....

>>> You have the wrong precedence for 'not'. As a unary operator, it
>>> should work like C's - (negate), !, ~.
>>
>> I am not copying C!
>
> I used C because that's widely known. But unary ops, in pretty much
> every language I've tried, always bind more tightly than binary ops. So
> they don't have meaningful precedence.
>
> (There might be the odd exception such as -A**B which in maths means
> -(A**B) not (-A)**B. Actually maths would be a good model for this:

Indeed, exceptions are not good. I wrestled with the
minus-exponentiation combo for a long time before setting on the
arithmetic group having its operators in the following order (high to low).

**
+ - (prefix)
* /
+ - (infix)

Note that I have attempted to be consistent between groups, where there
are corresponding operations. The bitwise group (currently) similarly
has shifts before bitnot. So

! a >> b

means

! (a >> b)

The order corresponds with the minus-exponentiation combo in the
arithmetic group.

Incidentally, in another case of not following C I use ! for bitnot.
That's because it is used to make other composite symbols with the same
meaning of unary negation and I preferred to try to be consistent. For
example,

! bitwise not
& bitwise and
!& bitwise nand

C's ~ didn't look good:

~&

....

>>>>    not (a < B < c)
>>>
>>> As written here that's fine. But I'd have a problem with making a
>>> special case for unary 'not':
>>>
>>>     not A < B       means not (A < B)? (I assume it applies to single >)
>>>     -A < B          means (-A) < B
>>
>> Why are you equating a boolean with an arithmetic operator? What
>> connection do you see between them?
>
> Both not and - (negate) are unary ops, and should be parsed the same
> way, regardless of what types they typically take.

Certainly! It would be far too confusing for a human to parse if the
other of evaluation changed for different types.

But one can still have bitwise not below bitwise shift, unary minus
below exponentiation, and boolean 'not' below comparisons which yield
False or True.

....

>>> These are my precedence levels:
>>>
>>>    8   **                             # highest
>>>
>>>    7   * / rem << >>
>>>    6   + - iand ior ixor
>>>    5   ..
>>>    4   = <> < <= >= > in notin
>>>    3   and
>>>    2   or
>>>
>>>    1   :=                             # lowest
>>
>> I have a different and arguably simpler order. Of those you mention,
>> highest to lowest I have
>>
>>    * bitwise ops
>>    * arithmetic ops
>>    * comparison ops
>>    * boolean ops
>>    * assignment ops
>
> That's the same as mine except that you treat bitwise ops (and or xor
> shifts) as higher than anything else, and in the same group?

Yes, the bitwise operations are all in the same group. It has: shifts,
not, and, xor, or in that order.

>
> But I don't believe this is the complete set of precedence levels,
> unless "+" has the same precedence as "*" so that:

What I listed was the families. Plus and times (+ and *) are both in the
'arithmetic' group. And times comes before plus.

>
>
>
>> So
>>
>>    not A gt B
>>
>> means
>>
>>    not (A gt B)
>>
>> If you think about it some more I believe you'll agree that it makes
>> sense and will immediately change your compiler and all your source
>> code to suit. ;-)
>
> This is interesting, because I used to write expressions like this:
>
>   if not (A in B)
>
> as without the parentheses, it would be (not A ) in B. But rather than
> introduce bizarre rules for 'not', contrary to every other language so
> it would cause confusion, I instead allowed:
>
>   if A not in B

I have that as

if not A in B

because 'in' comes before 'not'.

>
> However this doesn't work well or comparison ops, or with a chain of
> such ops.
>
> The only way your proposal can make sense, is for either a single
> comparison or chain of comparisons to bind so tightly that it forms a
> single term.

Well, the basic precedences have been in place for some time but if I
added chained comparisons then they (the chained comparisons) would be
treated as a composite subexpression of the same precedence as any other
comparison.

>
> So syntactically, A<B<C is treated like A.B.C.

I don't get that. I could have

if X and not (A < (B + 1) == C)

where none of the parens would be necessary.

>
> That means dispensing with normal precedence rules for comparison, which
> would have consequences:
>
>    if N + 1 <= Limit then ++N ...
>
> would end up being parsed as :
>
>    if N + (1 <= Limit) then ++N ...

Because arithmetic comes before comparison I would parse that as

if (N + 1) <= Limit

....

>>> Unary op are always applied first (but multiple unary ops on either
>>> side of a term - prefix and postfix - have their own rules).
>>
>> Having "their own rules" sounds as though it could be confusing.
>>
>> :-(
>
> This is to be in line with other languages. It means that this term:
>
>   op1 op2 X op3 op4
>
> is parsed as:
>
>   op1(op2(op4((op3 X))))

I agree with much of that. Postfix operators come first. But I don't put
all prefix operators so high.

Consider

- a & b ;i.e. negate (a bitand b)
- a ** b ;i.e. negate (a to the power of b)
not a & b ;i.e. boolean not of (a bitand b)

>
> In practice it works intuitively; you mustn't over-think it! So:
>
>   -P^     # ^ is a deref op

Mine does that. Of higher precedence than bitwise ops I have the
'operand' group which includes dereference. So I would have dereference
before unary negation.

The operand group essentially has

( invoke subprogram
[ array or slice
. member selection
& inhibit auto dereference
* dereference

All of the operators in that group are postfix, all have highest
precedence and all, therefore, associate left-to-right.

--
James Harris

On 06/09/2021 12:24, David Brown wrote:
> On 06/09/2021 12:41, Bart wrote:

....

>> [OK, this is a /fourth/ reply to you within half an hour. You should
>> stop saying things I disagree with!]
>>
>
> I've been interspersing with a few agreements...

Very lax. :-)

....

> If a language supports a concept of ranges, represented by "b .. c" (or
> similar syntax), then "a in b .. c" is a good way to handle such tests.
> I would not invent such a syntax purely for such tests,

I don't see the chaining of comparisons as only for range tests. AISI
where each 'op' is a comparison operator

A op B op C op D

simply means that all component parts have to be true for the whole
phrase to be true. In words,

(A op B) and (B op C) and (C op D)

> but if it is
> used for array slices, for-loops, etc., then you have a good feature.

I don't understand that. How can chaining be used for array slices, for
loops, etc?

>
>
> (Since I may have accidentally complemented you for a language feature,
> I need to add balance - don't you have a space key on your keyboard?
> Why don't you use it when writing code?)

Indeed!

In fairness, the absence of spaces doesn't look too bad when variable
names are short - such as might be used in example code fragments. But
IMO spaceless code becomes hard to read with longer identifiers as used
in proper programming.

--
James Harris

On 06/09/2021 18:03, James Harris wrote:
> On 06/09/2021 14:46, Bart wrote:

>> So syntactically, A<B<C is treated like A.B.C.
>
> I don't get that. I could have
>
>   if X and not (A < (B + 1) == C)
>
> where none of the parens would be necessary.

I mean that I have these broad levels

Syntax A() A.B A^ a[]
Unary -A +A abs A inot A istrue A not A ... and maths ops
Binary A+B etc

For comparison ops to bind more tightly than any unary, they'd have to
be in that top level, which would then lead to thse issues:

* A + B < C would bind in funny ways like my example

* Only A.B in the syntactic group has an infix 'shape', and there is now
ambiguity in A.B < C.D, which would be parsed as ((A.B) < C).D, unless I
now introduced different precedences at that level.

You get around that by allowing groups of unary ops in-between groups of
binary ops, but that's a little too outre for me.

>   - a & b    ;i.e. negate (a bitand b)

So - A & B means -(A & B), but - A * B still means (-A) * B ?

I really don't like precedences, or having to remember them, and tried
to keep them minimal:

** is unusual, so that's easy to remember

:= is at the other end, so that's easy too

* and /, and + and -, are known to everyone, and must go between those two.

That leaves comparisons, AND or OR. Comparisons can naturally go just
below normal expressions.

AND and OR I just remember from Pascal.

The full set is 6 levels:

Exponentiation

Scaling

Adding

Comparing (includes 'in/not in')

AND

OR

I can leave out assignment as you don't need to think about it; in many
languages you don't even have assignment in an expression. But when you
don't, it'll be lowest of all.

I haven't mentioned shifts and bitwise ops. Since shifts do scaling,
they can lumped in that group. The other bitwise ones are lumped with
add, since I can't think of a good reason they should be (a) higher
predence then Add; (b) lower precedence than Add.

(There is one more "..", which is an odd one out. There are problems at
every level, but I'm trying it out between Add and Compare. That one I
can never remember where it goes.)

On 06/09/2021 21:10, James Harris wrote:
> On 06/09/2021 12:24, David Brown wrote:

>>
>> (Since I may have accidentally complemented you for a language feature,
>> I need to add balance - don't you have a space key on your keyboard?
>> Why don't you use it when writing code?)
>
> Indeed!
>
> In fairness, the absence of spaces doesn't look too bad when variable
> names are short - such as might be used in example code fragments. But
> IMO spaceless code becomes hard to read with longer identifiers as used
> in proper programming.
>
>

It is a matter of style and opinion (and Bart knows that, of course).

But it is a serious point. Layout of code is vital to readability, and
spaces are a big part of that (as is consistency - you don't want
different spacing depending on the length of the variables). It is
better to write "c == 1" than "c==1", because the "==" is not part of
either then "c" or the "1". Some characters, such as parenthesis, are
thin enough that they provide their own visual space, and sometimes you
/do/ want to tie elements together closely and thus skip the space. The
details of a good spacing system are complicated, but I have no doubts
that the readability of Bart's code would be improved with more spaces.

I blame Knuth for my pedantry here. After having read "The TeX Book" in
my student days, I have been unable to ignore poor layout of code,
mathematics, or text. Lamport's "LaTeX" book didn't help either.

On 06/09/2021 22:24, David Brown wrote:

....

> I blame Knuth for my pedantry here. After having read "The TeX Book" in
> my student days, I have been unable to ignore poor layout of code,
> mathematics, or text. Lamport's "LaTeX" book didn't help either.

What's the exact title? I can find "Tex, The Program" but copies are too
expensive.

--
James Harris

On 07/09/2021 09:19, James Harris wrote:
> On 06/09/2021 22:24, David Brown wrote:
>
> ...
>
>> I blame Knuth for my pedantry here.  After having read "The TeX Book" in
>> my student days, I have been unable to ignore poor layout of code,
>> mathematics, or text.  Lamport's "LaTeX" book didn't help either.
>
> What's the exact title? I can find "Tex, The Program" but copies are too
> expensive.
>

"The TeXbook", by Donald Knuth.

"LaTeX : A Document Preparation System", by Leslie Lamport

These are not the smallest, cheapest or easiest introductions to TeX or
LaTeX if you want to use these systems - there is endless information
available for free online, as well as tutorial books, guides for more
specialist use in typesetting, etc.

But they are written by the authors of TeX and LaTeX respectively, and
give an understanding into the philosophy and technical details of
typesetting and good structured document layout. It is not just about
saying /how/ you make spaces of different sizes and stretchiness, but
saying /why/ you should do so, and when to use them.

On 06/09/2021 21:52, Bart wrote:
> On 06/09/2021 18:03, James Harris wrote:
>> On 06/09/2021 14:46, Bart wrote:
>
>>> So syntactically, A<B<C is treated like A.B.C.
>>
>> I don't get that. I could have
>>
>>    if X and not (A < (B + 1) == C)
>>
>> where none of the parens would be necessary.
>
>
> I mean that I have these broad levels
>
>   Syntax   A() A.B A^ a[]
>   Unary    -A +A  abs A  inot A  istrue A not A ... and maths ops
>   Binary   A+B etc
>
> For comparison ops to bind more tightly than any unary, they'd have to
> be in that top level,

Would they? Couldn't the same be achieved by allowing some of the
unaries to have lower levels - so that the issues you go on mention
wouldn't arise?

>
> which would then lead to thse issues:
>
> * A + B < C    would bind in funny ways like my example
>
> * Only A.B in the syntactic group has an infix 'shape', and there is now
> ambiguity in A.B < C.D, which would be parsed as ((A.B) < C).D, unless I
> now introduced different precedences at that level.
>
> You get around that by allowing groups of unary ops in-between groups of
> binary ops, but that's a little too outre for me.
>
>>    - a & b    ;i.e. negate (a bitand b)
>
> So - A & B means -(A & B), but - A * B still means (-A) * B ?

Yes, I have bitwise operations before arithmetic operations.

One could make a good case for prohibiting the combination of arithmetic
and bitwise operators because the first works on numbers and the second
works on bit patterns. The two do not match unless you require a mapping
between numbers and putative representations. But /if/ one decides that
they can be combined then one has to decide how they relate.

The worst place to put manipulation of bit patterns, ISTM, is between
arithmetic and comparisons. That's because arithmetic /produces/
numbers, while common comparisons (e.g. less-than) consume those
selfsame numbers. Bit patterns between those two would convert from
numbers to bit patterns then back to numbers. :-(

The only place left, /if/ one is to allow them to be combined, is to
carry out bitwise operations before doing arithmetic, and that's where
I've put them.

>
>
> I really don't like precedences, or having to remember them,

Nor me. But I found that keeping operators in families made their
ordering much easier to remember.

> and tried
> to keep them minimal:
>
> ** is unusual, so that's easy to remember
>
> := is at the other end, so that's easy too
>
> * and /, and + and -, are known to everyone, and must go between those two.
>
> That leaves comparisons, AND or OR. Comparisons can naturally go just
> below normal expressions.
>
> AND and OR I just remember from Pascal.
>
> The full set is 6 levels:
>
>    Exponentiation
>
>    Scaling
>
>    Adding
>
>    Comparing (includes 'in/not in')
>
>    AND
>
>    OR

That's interesting. You've taken a structural approach. I took a
semantic approach. IMO neither is provably best; there are options
rather than perfect solutions. The best possible is probably a
combination of convenience and memorability.

>
> I can leave out assignment as you don't need to think about it; in many
> languages you don't even have assignment in an expression. But when you
> don't, it'll be lowest of all.

Yes. I think that when explaining precedence levels it might be best to
start with the arithmetic operators and work up and down (in terms of
precedence level) from there.

>
> I haven't mentioned shifts and bitwise ops. Since shifts do scaling,
> they can lumped in that group. The other bitwise ones are lumped with
> add, since I can't think of a good reason they should be (a) higher
> predence then Add; (b) lower precedence than Add.

I recognise the dilemma. See above for where I ended up.

>
> (There is one more "..", which is an odd one out. There are problems at
> every level, but I'm trying it out between Add and Compare. That one I
> can never remember where it goes.)
>

I, too, have operators to fit in such as

Bitwise concatenation
Range specifiers

--
James Harris

On 06/09/2021 10:55, David Brown wrote:
> On 05/09/2021 12:50, James Harris wrote:
>> I've got loads of other posts in this ng to respond to but I came across
>> something last night that I thought you might find interesting.
>>
>> The issue is whether a language should support chained comparisons such
>> as where
>>
>>   A < B < C
>>
>> means that B is between A and C? Or should a programmer have to write
>>
>>   A < B && B < C
>>
>> ?
>>
>
> Ask yourself if the need to check that a value is within a range is
> common enough that you need a special syntax to handle it. I'd say no,

If this were about just checking whether a value was in range I would
say the same.

> but there is always a balance to be found and it varies from language to
> language. I am not a fan of having lots of special syntaxes, or
> complicated operators - whether they are done using symbols or vast
> numbers of keywords.

Nor me.

>
> My vote would be to make relational operators return a "boolean", and to
> make operations between booleans and other types a syntax error or
> constraint error, and to disallow relational operators for booleans.
> Then "A < B < C" is a compile-time error. It is not particularly hard
> to write "A < B && B < C" when you need it. Put more focus on making it
> hard to write incorrect or unclear code.
>

Interesting that you should say that. For me, the main appeal of chained
or composite comparisons is that they can make code /easier/ to read.
Yes, there are ranges - with or without inclusivity as in

low <= v <= high
0 <= index < len

Though it's not just about ranges. For example,

low == mid == high

Some such as

x < y > z

is not, by itself, so intuitive. But as you say, they can all be read as
written with "and" between the parts. In this case,

x < y && y > z

I haven't yet decided whether or not to include composite comparisons
but I can see readability benefits.

--
James Harris