On 06/09/2021 11: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

....

>>  It is not particularly hard
>> to write "A < B && B < C" when you need it.
>
> * B has to be written twice

True.

>
> * 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

Two very good points!

--
James Harris

On Saturday, October 23, 2021 at 10:40:03 AM UTC-4, James Harris wrote:

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

to uppercase a byte:
if 'a' is less than or equal to the byte is less than or equal to 'z' ?
subtract 32 from the byte;
end;

to decide if a byte is any letter:
return true if 'A' is less than or equal to the byte is less than or equal to 'Z' or
if 'a' is less than or equal to the byte is less than or equal to 'z';
return false;
end;

Mike Gonta
now -i know how to compile

https://the-ideom.com/

On 23/10/2021 15:39, James Harris wrote:

> 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.

If you don't have chained comparisons, then you have to decide what a <
b < c or a = b = c mean. Where there isn't an intuitive alternative
meaning, then you might as well use that syntax to allow chains.

But you might want to restrict it so that the sequence of comparisons
are either all from (< <= =) or (> >= =).

So that if you were to plot the numeric values of A op B op C for
example when the result is True, the gradient would always be either >=
0 or <= 0; never mixed; ie no ups then downs.

(Which also allows you to infer the relationship of A and C).

Then, x < y > z would not be allowed (it's too hard to grok); neither
would x != y != z, even if it is equivalent to:

x != y and y != z

(That is better written as y != x and y != z; I would write it as y not
in [x, z])

On 27/10/2021 01:15, Bart wrote:
> If you don't have chained comparisons, then you have to decide what
> a < b < c or a = b = c mean. Where there isn't an intuitive alternative
> meaning, then you might as well use that syntax to allow chains.

/Syntactically/, "a < b < c" is correct [FSVO!] in most
languages, and if not it's because the semantics are obtruding
into the syntax in ways that they ought not to. IOW, "a + b + c"
is correct syntax almost no matter how you slice and dice, and
there is no interesting syntactic difference between that and the
"<" case. Both of these fail [if they do] because of the types
of "a" [etc], not because "a OP b OP c" is a forbidden construct.

So really, this is a question of the semantics of "a < b".
We really, really don't want to mess around too much with "a < b"
itself, or else we all get confused. The trouble then is that
conventionally "a < b" returns Boolean and throws away the "b".
Effectively, you either have [eg] "TRUE < c" [which is either
meaningless or very likely not what the perpetrator intended] or
else you have to "special case" "a < b < c" so that "b" is kept
around, and so that "a < b" means one thing if that is the whole
expression and means something quite different if it is the left
operand of another operator. Special-casing is clearly possible,
esp in a private language, but it's not desirable in general.
So we "need" a new operator.

All of which set me thinking about how to do it, or at
least something close to "it", in languages with user-defined
operators. The following is what I came up with for Algol 68G
[it's a complete program -- explanations available if anyone is
actually interested]:

====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ======

PRIO +< = 5, +> = 5, +<= = 5, +>= = 5, += = 4, +/= = 4;
MODE IB = STRUCT (INT i, BOOL b);
OP +< = (INT i,j) IB: ( i < j | (j, TRUE) | (~, FALSE) ),
< = (IB p, INT k) BOOL: ( b OF p | i OF p < k | FALSE ),
+< = (IB p, q) IB:
( b OF p | (i OF q, i OF p < i OF q) | (~, FALSE) ),
+< = (IB p, INT k) IB:
( b OF p | (k, i OF p < k) | (~, FALSE) ),
+< = ([] INT a) BOOL:
IF UPB a <= LWB a THEN TRUE # vacuously #
ELSE INT p := a [LWB a];
FOR i FROM LWB a + 1 TO UPB a
DO ( p < a[i] | p := a[i] | e ) OD;
TRUE EXIT e: FALSE
FI;
# Repeat the above for the other five operators #

# Use as, for example: #
print ( 1 +< 2 +< 3 < 4);
print ( +< [] INT (1, 2, 3, 4, 5, 6) );
# cast needed as the MODE (type) of (1,2,3,...) is
not fully determined by the syntax in this position #
[] INT c = (6, 5, 4, 3, 2, 1); print ( +< c ) # no cast! #
# prints "TTF" #

====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ======

I initially used "<<" as the new operator, but [for good if obscure
reasons] that can't be used as a monadic operator in Algol. More
generally, it's not hard to write new operators such that [eg]

IF 0 +< [] INT (a,b,c) +<= 100 THEN ...

works. Whether that's worth doing is another matter. It's neater
and [perhaps] more readable than

IF a > 0 AND a <= 100 AND b > 0 AND ...

but I've managed without over several decades of programming and
can't claim ever to have missed it.

> But you might want to restrict it so that the sequence of comparisons
> are either all from (< <= =) or (> >= =).
[...]
> Then, x < y > z would not be allowed (it's too hard to grok); [...]
ISTM harder to restrict it than to allow it. But again
whether it's worth doing [whether at all, or with restrictions]
is another matter. I doubt it; but it makes a nice little
programming exercise.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Boccherini

On 28/10/2021 20:37, Andy Walker wrote:
> On 27/10/2021 01:15, Bart wrote:
>> If you don't have chained comparisons, then you have to decide what
>> a < b < c or a = b = c mean. Where there isn't an intuitive alternative
>> meaning, then you might as well use that syntax to allow chains.
>
>     /Syntactically/, "a < b < c" is correct [FSVO!] in most
> languages, and if not it's because the semantics are obtruding
> into the syntax in ways that they ought not to.  IOW, "a + b + c"
> is correct syntax almost no matter how you slice and dice, and
> there is no interesting syntactic difference between that and the
> "<" case.  Both of these fail [if they do] because of the types
> of "a" [etc], not because "a OP b OP c" is a forbidden construct.
>
>     So really, this is a question of the semantics of "a < b".
> We really, really don't want to mess around too much with "a < b"
> itself, or else we all get confused.  The trouble then is that
> conventionally "a < b" returns Boolean and throws away the "b".
> Effectively, you either have [eg] "TRUE < c" [which is either
> meaningless or very likely not what the perpetrator intended] or
> else you have to "special case" "a < b < c" so that "b" is kept
> around, and so that "a < b" means one thing if that is the whole
> expression and means something quite different if it is the left
> operand of another operator.  Special-casing is clearly possible,
> esp in a private language, but it's not desirable in general.
> So we "need" a new operator.
>
>     All of which set me thinking about how to do it, or at
> least something close to "it", in languages with user-defined
> operators.  The following is what I came up with for Algol 68G
> [it's a complete program -- explanations available if anyone is
> actually interested]:
>
> ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ======
>
>   PRIO +< = 5, +> = 5, +<= = 5, +>= = 5, += = 4, +/= = 4;
>   MODE IB = STRUCT (INT i, BOOL b);
>   OP +< = (INT i,j) IB: ( i < j | (j, TRUE) | (~, FALSE) ),
>      <  = (IB p, INT k) BOOL: ( b OF p | i OF p < k | FALSE ),
>      +< = (IB p, q) IB:
>             ( b OF p | (i OF q, i OF p < i OF q) | (~, FALSE) ),
>      +< = (IB p, INT k) IB:
>             ( b OF p | (k, i OF p < k) | (~, FALSE) ),
>      +< = ([] INT a) BOOL:
>              IF UPB a <= LWB a THEN TRUE          # vacuously #
>                ELSE INT p := a [LWB a];
>                     FOR i FROM LWB a + 1 TO UPB a
>                        DO ( p < a[i] | p := a[i] | e ) OD;
>                     TRUE EXIT e: FALSE
>              FI;
>     # Repeat the above for the other five operators #
>
>     # Use as, for example: #
>       print ( 1 +< 2 +< 3 < 4);
>       print ( +< [] INT (1, 2, 3, 4, 5, 6) );
>          # cast needed as the MODE (type) of (1,2,3,...) is
>            not fully determined by the syntax in this position #
>       [] INT c = (6, 5, 4, 3, 2, 1); print ( +< c ) # no cast! #
>     # prints "TTF" #

Well, this works, for your examples.

But I think that with working on arrays, that's straying from what this
is about; that is more like list operators, where you apply a designated
operator between all elements of the array to get a single scalar result.

I may have mentioned the way I approach this, which is to consider a
chain of related operators as a single n-ary operator.

This can be implemented by transforming A op1 B op2 C into (A op1 B) and
(B op2 C), but I now treat it as a single operation, with a composite
operator and multiple operands.

That has worked very well, and implemented much more simply when
built-in to a compiler, than trying to do it with language-building
features, as your example shows. For example, my way works for any types
for which < <= >= > are defined, for any types at all when only = <> are
involved, and it will work with mixed types.

(But I don't have list ops, which is a different subject.)

> ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ====== 8< ======
>
> I initially used "<<" as the new operator, but [for good if obscure
> reasons] that can't be used as a monadic operator in Algol.  More
> generally, it's not hard to write new operators such that [eg]
>
>   IF 0 +< [] INT (a,b,c) +<= 100 THEN ...
>
> works.  Whether that's worth doing is another matter.

And what it actually means is another! I can't relate it what you write
below ...

  It's neater
> and [perhaps] more readable than
>
>   IF a > 0 AND a <= 100 AND b > 0 AND ...

.... which I'd anyway write as:

if a in 1..100 and b>0 then

I wouldn't use chained compares at all, as this is even better. Syntax
is so easy to add to a language!

> but I've managed without over several decades of programming and
> can't claim ever to have missed it.

I wouldn't like to go back to whatever I was using in the mid-80s...

>> But you might want to restrict it so that the sequence of comparisons
>> are either all from (< <= =) or (> >= =).
> [...]
>> Then, x < y > z would not be allowed (it's too hard to grok); [...]
>     ISTM harder to restrict it than to allow it.

I've just done it; it took 3 minutes, and some 8 lines of code. So
you're right, it was harder by requiring some extra effort and mode
code, but it probably saves some head-scratching later.

On 29/10/2021 01:03, Bart wrote:

> That has worked very well, and implemented much more simply when
> built-in to a compiler, than trying to do it with language-building
> features, as your example shows. For example, my way works for any types
> for which < <= >= > are defined, for any types at all when only = <> are
> involved,

> and it will work with mixed types.

Well, sort of. I thought I better try. It appears to work, but it
converts all the operands to a common, dominant type. So A=B=C could
have different semantics compared with A=B and B=C, as the former could
use all floats; the latter might use int for A=B and floats for B=C.

On 2021-10-28 21:37, Andy Walker wrote:

>     /Syntactically/, "a < b < c" is correct [FSVO!] in most
> languages, and if not it's because the semantics are obtruding
> into the syntax in ways that they ought not to.

It is worth to mention that originally

a < b < c

is not an expression. It is a proposition and it is also meant to convey
transitivity. a is less than b and also less than c. For that reason

a < b > c

is not used, rather

a,c < b

while

a < b < c < d

is pretty common to define an ordered set.

An imperative programming language does not need any of that. Inclusion
tests are better with intervals

b in a..c

sets are better with aggregates

(a,b,c,d)

A declarative language would have to keep expressions apart from
declarations anyway.

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

On 29/10/2021 07:27, Dmitry A. Kazakov wrote:
> It is worth to mention that originally
>    a < b < c
> is not an expression. It is a proposition and it is also meant to convey transitivity. a is less than b and also less than c. For that reason
>    a < b > c
> is not used,

Sure. But once you've added operators to do chained
comparisons, it's harder to prevent "a < b > c" than just to
accept it; it's not as though the meaning is unclear. [OTOH,
I suppose it could be a typo, but OTTH I can't imagine using
any of this in my own programming.]

> rather
>    a,c < b

This is OK as maths, but in many computing languages
it's syntactically ambiguous. In Algol, you'd need to
decorate it something like "[]INT (a,b) < c" plus writing
the [newly extended] operator. Again, it all seems like a
lot of trouble to avoid "a < b AND c < b", or, if "b" is a
complicated expression "(INT b = some mess; a < b AND c < b)".
Note that "a < b >= c" is slightly harder to re-cast, tho' it
comes free with the chaining operators.

> while
>    a < b < c < d
> is pretty common to define an ordered set.

Again, this drops out with no extra work once the
chaining operators are written; equally again, it's not
sufficiently common in programming to justify much work
being done for it, and esp not to justify extra syntax.

> An imperative programming language does not need any of that.
> Inclusion tests are better with intervals
> b in a..c
> sets are better with aggregates
> (a,b,c,d)

No doubt, but I don't want to have to mess with the
compiler to add and use them.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Chwatal

On 2021-10-29 21:29, Andy Walker wrote:
> On 29/10/2021 07:27, Dmitry A. Kazakov wrote:

>> An imperative programming language does not need any of that.
>> Inclusion tests are better with intervals
>>    b in a..c
>> sets are better with aggregates
>>    (a,b,c,d)
>
>     No doubt, but I don't want to have to mess with the
> compiler to add and use them.

They can be well used for many other purposes starting with cycles

for I in 1..200
for I in (a,b,c,d)

while chained operations have no use at all, except for renaming an
object like b in

a < b < c

Yet it is too specific to serve numerous other cases one could need a
renaming:

b = b + c

I would expect at least that, e.g. in the evil spirit of C:

b += c
a < b <&& c

(:-))

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

On 29/10/2021 01:03, Bart wrote:
>> [...] More
>> generally, it's not hard to write new operators such that [eg]
>>    IF 0 +< [] INT (a,b,c) +<= 100 THEN ...
>> works.  Whether that's worth doing is another matter.
> And what it actually means is another! I can't relate it what you write below ...
>>   It's neater
>> and [perhaps] more readable than
>>    IF a > 0 AND a <= 100 AND b > 0 AND ...
> ... which I'd anyway write as:
>    if a in 1..100 and b>0 then

That's only the first half of it! Or did you miss the "..."?
Put differently, it meant "a" and "b" and "c" all > 0 and <= 100.
[NB, "a > 0" is equivalent to "a >= 1" for integers, but not for
reals. But that's another can of worms.]

> I wouldn't use chained compares at all, as this is even better.

I've never used them in programming [until yesterday!].

> Syntax is so easy to add to a language!

Syntax is easy to change in your own private language,
but I don't expect any ideas you or I or even Dmitri may have
to propagate any time soon to C or Fortran or Pascal or ....
It is essentially impossible to make any major changes to those
languages that have standards; it's also quite hard to make
sure that syntax changes don't impact (a) on legacy programs,
and (b) other parts of the syntax. If /you/ bungle in this
sort of way in /your/ language, you can quietly revert to the
old version of the compiler; if the C committee does something
daft, chaos ensues, which is why they are /extremely/ cautious.

[...]
> I wouldn't like to go back to whatever I was using in the mid-80s...

In my case, that would be primarily C [tho' thenabouts
I was jointly giving a module on comparative languages, and we
got through something like 20 languages in as many lectures,
with tops-and-tails describing various types of language and
projects in about six of them]. But C was merely the best of
a bad job [esp given the then-available resources and compilers
-- we had 2.4MB discs and 64KB limits on code and data on our
PDP-11 (with over 100 users and ~40 terminals)]. Personally,
I gradually became more and more bored with writing C programs,
and largely switched to shell scripts and similar. When A68G
came along, I suddenly regained the joy of programming, and of
using a language instead of fighting it. But that's back to
the '70s!

>>> But you might want to restrict it so that the sequence of comparisons
>>> are either all from (< <= =) or (> >= =).
>> [...]
>>> Then, x < y > z would not be allowed (it's too hard to grok); [...]
>>      ISTM harder to restrict it than to allow it.
> I've just done it; it took 3 minutes, and some 8 lines of code. So
> you're right, it was harder by requiring some extra effort and mode
> code, but it probably saves some head-scratching later.

When you say you've done it, you mean you've tweaked your
compiler. More important from my PoV is to explain it to users,
inc re-writing the "User Manual" to include the new syntax. For
that purpose, it's easier to say that all comparison operators can
be "chained", giving examples, than to say "these can be chained,
separately those can be chained, but you can't mix them, except
for the [in]equality operators", with a sub-text of "because you
wouldn't understand what they meant, so don't trouble your pretty
head about it". I made the last bit up, but it's the impression
I often get from patronising user manuals and textbooks.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Chwatal

On 30/10/2021 00:18, Andy Walker wrote:
> On 29/10/2021 01:03, Bart wrote:
>>> [...] More
>>> generally, it's not hard to write new operators such that [eg]
>>>    IF 0 +< [] INT (a,b,c) +<= 100 THEN ...
>>> works.  Whether that's worth doing is another matter.
>> And what it actually means is another! I can't relate it what you
>> write below ...
>>>                               It's neater
>>> and [perhaps] more readable than
>>>    IF a > 0 AND a <= 100 AND b > 0 AND ...
>> ... which I'd anyway write as:
>>     if a in 1..100 and b>0 then
>
>     That's only the first half of it!  Or did you miss the "..."?
> Put differently, it meant "a" and "b" and "c" all > 0 and <= 100.
> [NB, "a > 0" is equivalent to "a >= 1" for integers, but not for
> reals.  But that's another can of worms.]

If your example was short of the extra clutter, then it would be:

if 0 < (a,b,c) <= 100 then

It's a little clearer what's happening, but this list processing is
still causing some confusion. You've taken a chain of compare operators,
and combined that with list operations. So what would:

0 < (a,b,c) < (d,e,f)

mean? Your original also has ambiguities: should the result be a single
value (True when 0 < x <= 100 for every x in (a,b,c))? Or should it be:

(True, False, True)

which is the the set of booleans from each 0 < x <= 100?

So this is a sort of red herring when talking about the benefits of
chained compares.

>> I wouldn't use chained compares at all, as this is even better.
>
>     I've never used them in programming [until yesterday!].
>
>> Syntax is so easy to add to a language!
>
>     Syntax is easy to change in your own private language,

It's easy to add syntax in a new language. And it really isn't hard in
an established language.

Where do you think all those new features in sucessive C standards come
from? It is specific implementations adding extensions.

So &&L in gnu C is special syntax to take the address of a label.
(Needed because labels live in their own namespace, and so &L would be
ambiguous.)

> It is essentially impossible to make any major changes to those
> languages that have standards;  it's also quite hard to make
> sure that syntax changes don't impact (a) on legacy programs,
> and (b) other parts of the syntax.

See above. On the subject of C, see also C++.

>  If /you/ bungle in this
> sort of way in /your/ language, you can quietly revert to the
> old version of the compiler;  if the C committee does something
> daft, chaos ensues, which is why they are /extremely/ cautious.

C syntax was already chaotic, it can't get much worse!

Eg. 'break' being overloaded; a*b meaning multiply a by b, OR declare
variable b of type 'pointer to a'.

I've switched machines so DAK's posts are visible again; but he suggests
syntax like this:

for I in 1..200
for I in (a,b,c,d)

which is exactly what I use (with the addition of 'do'). The first works
in both of my languages; the second only in the higher level one. The
meanings are obvious.

But, probably half of current languages have copied C's brain-dead
for-loop syntax for that first example:

for (i = 1; i <= 200; ++i)

(More typically, 0..199 for such languages as they tend to be 0-based
too, /and/ case-sensitive.)

What is the matter with people?! This is the compiler's job to know how
to implement iteration, not yours!

> [...]
>> I wouldn't like to go back to whatever I was using in the mid-80s...
>
>     In my case, that would be primarily C [tho' thenabouts
> I was jointly giving a module on comparative languages, and we
> got through something like 20 languages in as many lectures,
> with tops-and-tails describing various types of language and
> projects in about six of them].  But C was merely the best of
> a bad job [esp given the then-available resources and compilers
> -- we had 2.4MB discs and 64KB limits on code and data on our
> PDP-11 (with over 100 users and ~40 terminals)].

(Really? I feel fortunate now in sharing my pdp11/34 with only 1-2 other
people!)

> Personally,
> I gradually became more and more bored with writing C programs,
> and largely switched to shell scripts and similar.  When A68G
> came along, I suddenly regained the joy of programming, and of
> using a language instead of fighting it.  But that's back to
> the '70s!

You've illustrated perfectly why I still prefer using my own languages!

But I couldn't use A68; I'd be constantly fighting the syntax and tyope
system. And switching between capitals and lower case all the time...

>>>> But you might want to restrict it so that the sequence of comparisons
>>>> are either all from (< <= =) or (> >= =).
>>> [...]
>>>> Then, x < y > z would not be allowed (it's too hard to grok); [...]
>>>      ISTM harder to restrict it than to allow it.
>> I've just done it; it took 3 minutes, and some 8 lines of code. So
>> you're right, it was harder by requiring some extra effort and mode
>> code, but it probably saves some head-scratching later.
>
>     When you say you've done it, you mean you've tweaked your
> compiler.  More important from my PoV is to explain it to users,
> inc re-writing the "User Manual" to include the new syntax.

That would just be a Note: you can only mix '= < <=' or '= > >='.

(But don't try to explain further or you'd get tied up in knots.)

> For
> that purpose, it's easier to say that all comparison operators can
> be "chained", giving examples, than to say "these can be chained,
> separately those can be chained, but you can't mix them, except
> for the [in]equality operators", with a sub-text of "because you
> wouldn't understand what they meant, so don't trouble your pretty
> head about it".

It can be to avoid confusion and to be keep things readable.

On 2021-10-30 13:32, Bart wrote:

> If your example was short of the extra clutter, then it would be:
>
>  if 0 < (a,b,c) <= 100 then
>
> It's a little clearer what's happening, but this list processing is
> still causing some confusion. You've taken a chain of compare operators,
> and combined that with list operations. So what would:
>
>    0 < (a,b,c) < (d,e,f)
>
> mean?

Depends on the lists. Actually the above is abbreviations or OR-list vs
AND-lists. Depending on that you expand macros (because these are
actually macros rather than operations):

0 < AND(a,b,c) < AND(d,e,f) --- expand --->

--- expand ---> (0 < a < d) and (0 < a < e) and (0 < a < f) ...

Here "and" is a proper logic operation.

> Your original also has ambiguities: should the result be a single
> value (True when 0 < x <= 100 for every x in (a,b,c))? Or should it be:
>
>    (True, False, True)
>
> which is the the set of booleans from each 0 < x <= 100?

It is unambiguous because "for every x in (a,b,c)" makes the list a
macro list AND(a,b,c). When you move "for every x" to the leftmost
position you reduce in to a proper operation "and". The macro rule is:

for every x in (y, ...) do z --- expand --->

--- expand ---> (x do z) and (for every x in (...) do z)

for every x in () do z --- expand ---> True

You could also have "exists" quantification:

for any x in (y, ...) do z --- expand --->

--- expand ---> (x do z) or (for any x in (...) do z)

for any x in () do z --- expand ---> False

> So this is a sort of red herring when talking about the benefits of
> chained compares.

It is actually a macro as well that expands

LESS(a,b,c)

into proper operations a < b and b < c. It is possible to "overload"
LESS with < to keep the syntax same for both. Then you resolve the
conflict since for

1 < 2 < 3

there is no Boolean < int and you decide in favor of LESS. But in

1 < 2 and x

there is no LESS and x and you decide for comparison. But then you could
not have ordered Booleans.

> I've switched machines so DAK's posts are visible again; but he suggests
> syntax like this:

Yes, my own machines hate me too! (:-))

>> For
>> that purpose, it's easier to say that all comparison operators can
>> be "chained", giving examples, than to say "these can be chained,
>> separately those can be chained, but you can't mix them, except
>> for the [in]equality operators", with a sub-text of "because you
>> wouldn't understand what they meant, so don't trouble your pretty
>> head about it".

You do not want

a or b < c

to mean

(a < c) or (b < c)

It is a funny stuff, e.g.

(a and b) * (c or d) >= 100

means

((a * c) or (a * d) >= 100) and ((b * c) or (b * d) >= 100)

Cool, no? Even better, what about this one

(a xor b) > c

(:-))

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

On 30/10/2021 13:22, Dmitry A. Kazakov wrote:
> On 2021-10-30 13:32, Bart wrote:
>
>> If your example was short of the extra clutter, then it would be:
>>
>>   if 0 < (a,b,c) <= 100 then
>>
>> It's a little clearer what's happening, but this list processing is
>> still causing some confusion. You've taken a chain of compare
>> operators, and combined that with list operations. So what would:
>>
>>     0 < (a,b,c) < (d,e,f)
>>
>> mean?
>
> Depends on the lists. Actually the above is abbreviations or OR-list vs
> AND-lists. Depending on that you expand macros (because these are
> actually macros rather than operations):
>
>    0 < AND(a,b,c) < AND(d,e,f) --- expand --->
>
>    --- expand ---> (0 < a < d) and (0 < a < e) and (0 < a < f) ...
>
> Here "and" is a proper logic operation.

That's one interpretation of it. And one implementation.

For example, it's not clear what happened to b and c, unless they will
each also be compared against d, e and f. (Making it more like a matrix
operation.)

>
>> Your original also has ambiguities: should the result be a single
>> value (True when 0 < x <= 100 for every x in (a,b,c))? Or should it be:
>>
>>     (True, False, True)
>>
>> which is the the set of booleans from each 0 < x <= 100?
>
> It is unambiguous because "for every x in (a,b,c)" makes the list a
> macro list AND(a,b,c).

It's ambiguous because there is more than one intuitive result. For the
scalar-vector example:

x op (a, b, c)

one result might be:

(x op a, x op b, x op c)

which is a list of bools when op is "<". However you might want to take
that further and make it:

x op a and x op b and x op c

to yield a single bool result. But the original has a chain of related
ops. Maybe that one should be equivalent to either:

(0 < a <= 100, 0 < b <= 100, 0 < c <= 100)

Or the same collapsed down to one bool. This suggests there would be a
choice between those possibilities. It also requires that where this is
a mix of scalar and vector terms, the scalar terms should be treated as
a repeated vector of that term.

But then, you will have other kinds of operators where that doesn't make
sense.

A vector- or list-processing language needs careful design.

> You do not want
>
>    a or b < c
>
> to mean
>
>    (a < c) or (b < c)
>
> It is a funny stuff, e.g.
>
>
>    (a and b) * (c or d) >= 100
>
> means
>
>    ((a * c) or (a * d) >= 100) and ((b * c) or (b * d) >= 100)
>
>
> Cool, no? Even better, what about this one
>
>    (a xor b) > c
>
> (:-))

Those are all weird constructions at odds with the normal precedences of
< and 'or'. Here:

(a and b) * (c or d) >= 100

it looks like you're multiplying two bools, then comparing that result
with 100. It would need special operators. But I still don't understand
what's happening even if your expand version.

On 2021-10-30 18:36, Bart wrote:
> On 30/10/2021 13:22, Dmitry A. Kazakov wrote:
>> On 2021-10-30 13:32, Bart wrote:
>>
>>> If your example was short of the extra clutter, then it would be:
>>>
>>>   if 0 < (a,b,c) <= 100 then
>>>
>>> It's a little clearer what's happening, but this list processing is
>>> still causing some confusion. You've taken a chain of compare
>>> operators, and combined that with list operations. So what would:
>>>
>>>     0 < (a,b,c) < (d,e,f)
>>>
>>> mean?
>>
>> Depends on the lists. Actually the above is abbreviations or OR-list
>> vs AND-lists. Depending on that you expand macros (because these are
>> actually macros rather than operations):
>>
>>     0 < AND(a,b,c) < AND(d,e,f) --- expand --->
>>
>>     --- expand ---> (0 < a < d) and (0 < a < e) and (0 < a < f) ...
>>
>> Here "and" is a proper logic operation.
>
> That's one interpretation of it. And one implementation.
>
> For example, it's not clear what happened to b and c, unless they will
> each also be compared against d, e and f. (Making it more like a matrix
> operation.)

If you mean vectors, they are not comparable. But yes, this is a reason
why am against such things. To me (a,b,c) is an aggregate that can be of
any user-defined type, which then determines the meaning of <.
Everything is overloaded and everything is typed.

>>> Your original also has ambiguities: should the result be a single
>>> value (True when 0 < x <= 100 for every x in (a,b,c))? Or should it be:
>>>
>>>     (True, False, True)
>>>
>>> which is the the set of booleans from each 0 < x <= 100?
>>
>> It is unambiguous because "for every x in (a,b,c)" makes the list a
>> macro list AND(a,b,c).
>
> It's ambiguous because there is more than one intuitive result. For the
> scalar-vector example:
>
>   x op (a, b, c)
>
> one result might be:
>
>   (x op a, x op b, x op c)

Yes, if op is *, () is vector, x is scalar. Then

2 * (3,4,5) = (6,8,10)

> A vector- or list-processing language needs careful design.

Just provide user-defined types, user-defined aggregates etc. The
programmer will sort things out. Less you wire in the syntax, easier it
would be for everybody.

>> You do not want
>>
>>     a or b < c
>>
>> to mean
>>
>>     (a < c) or (b < c)
>>
>> It is a funny stuff, e.g.
>>
>>
>>     (a and b) * (c or d) >= 100
>>
>> means
>>
>>     ((a * c) or (a * d) >= 100) and ((b * c) or (b * d) >= 100)
>>
>>
>> Cool, no? Even better, what about this one
>>
>>     (a xor b) > c
>>
>> (:-))
>
> Those are all weird constructions at odds with the normal precedences of
> < and 'or'. Here:
>
>   (a and b) * (c or d) >= 100
>
> it looks like you're multiplying two bools, then comparing that result
> with 100. It would need special operators. But I still don't understand
> what's happening even if your expand version.

Yes, for that reason you either use an alternative notation, e.g. | is
frequently used to separate alternatives:

case X is
when 1 | 4 | 40 =>
Do something
when ...
end case;

Or you use quantifiers as Andy did:

forall x in (a, b) exists y in (c, d) such that x*y >= 100

removing free variables x, y:

all(a, b) * any(c, d) >= 100

The last step:

(a and b) * (c or d) >= 100

Again, not that I advocate for this stuff.

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

On 30/10/2021 12:32, Bart wrote:
> [...] So what would:
>    0 < (a,b,c) < (d,e,f)
> mean?

Whatever you wanted it to mean. As Dmitri proposed and
[long ago ...] Algol specified, all operators [inc standard ones
such as "+" and "AND"] are in "user space". You can define or
re-define them as you choose. Your program is embedded in an
environment in which lots of things are defined for you, but you
don't have to stick with the normal definitions. It will all be
visible in your code, so it's up to you whether you choose to
confuse yourself or not.

> Your original also has ambiguities: should the result be a single
> value (True when 0 < x <= 100 for every x in (a,b,c))? Or should it
> be:
>    (True, False, True)
> which is the the set of booleans from each 0 < x <= 100?

That may be an ambiguity in your own mind, but when you
write your program you will have to decide what it means, and
there is no reason why what you decide has to be the same as
what Dmitri and I decide.

> So this is a sort of red herring when talking about the benefits of
> chained compares.

As previously noted, I've never felt the need to use
"chained" compares, so I'm not going to start talking now
about the benefits of them [for programs, as opposed to in
mathematics, where some usages are well understood].

[...]
> It's easy to add syntax in a new language. And it really isn't hard
> in an established language.
> Where do you think all those new features in sucessive C standards
> come from? It is specific implementations adding extensions.

Most of them came from Algol! Each new standard thus
far has added something from Algol, and AFAIR nothing that is
Algol-like has ever been taken away. [In view of discussions
with Brian Kernighan, I would like to take some credit for this,
but I really can't, and expect Steve Bourne was much more of an
influence!]

> So &&L in gnu C is special syntax to take the address of a label.
> (Needed because labels live in their own namespace, and so &L would
> be ambiguous.)

It's not /needed/. It's a way of creating botches.
Lots of early languages had label variables, and associated
paraphernalia, and gradually mainstream languages dropped
them. I'm not a subscriber to "all labels are evil" [there
was one, and an elided "GOTO", in the code I showed], but
there is very much less need for them today than there was
[or seemed to be] in the '50s and '60s.

[...]
> C syntax was already chaotic, it can't get much worse!

K&R C syntax totals about 5 1/2 sides in a manual of
31 sides. Compare the latest standard and weep. Then look
at the C++ standard, and weep some more. Then look at the
debates in "cmp.std.c" and weep more again. For comparison,
the Algol syntax chart in "Algol Bulletin" is one side, tho'
admittedly it doesn't include formats [an Algol botch, that
would surely have been removed had Algol ever been revised
after looking at Unix], another half side.

> Eg. 'break' being overloaded; a*b meaning multiply a by b, OR declare
> variable b of type 'pointer to a'.

That's the sort of thing that happens when a private
language goes public before it is properly defined, and
without proper critical scrutiny. Sadly, that has been the
norm ever since it became standard practice for programmers
to write their own languages, loosely based on C or some
other currently popular language, write a paper or a web
page about the result, and sit back and wait for some of
them to thrive [usually for not-very-good reasons].

[...]
> But I couldn't use A68; I'd be constantly fighting the syntax and
> tyope system.

That's because you haven't read the RR!.

> And switching between capitals and lower case all the
> time...

That's up to you. Any full implementation should
allow you the choice between upper-case stropping, reserved-
word stropping, prefix-apostrophe stropping, prefix-period
stropping and [perhaps] lower-case stropping, also a choice
of character sets [all this long before it became normal to
send programs around the world electronically, so that the
"internationalisation" effort became important]. I often
write code snippets for here in reserved-word, as it makes
the code look a bit more friendly. It's straightforward
[-ish] to write preprocessors that convert between regimes.

[...]
>>      When you say you've done it, you mean you've tweaked your
>> compiler.  More important from my PoV is to explain it to users,
>> inc re-writing the "User Manual" to include the new syntax.
> That would just be a Note: you can only mix '= < <=' or '= > >='.

Note again that in Algol "chained" comparisons, if
you choose to use them, are entirely private grief, and no
change to any syntax is required. But "Notes" aren't what
a User Manual is about, though it can be useful to put
supplementary information into a footnote, comment or example.
The Manual is for the Truth, the Whole Truth and Nothing But
the Truth. If your language allows you to mix some operators
but not others, then the syntax should reflect that [which,
in the present case would make the syntax more complicated].

> (But don't try to explain further or you'd get tied up in knots.)

How patronising!

> It can be to avoid confusion and to be keep things readable.

Readability and confusions of user programs are not
to do with the User Manual but with style and good usage.
By all means put appropriate comments in footnotes, but the
Manual is the place where the actual syntax and semantics
of the language are "officially" defined, not where the
proles are told what the High Priests deign to allow them
to know. Some of the proles may well be better and more
experienced programmers than the High Priests.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Byrd

On 30/10/2021 22:10, Andy Walker wrote:
> On 30/10/2021 12:32, Bart wrote:
>> [...] So what would:
>>     0 < (a,b,c) < (d,e,f)
>> mean?
>
>     Whatever  you wanted it to mean.  As Dmitri proposed and
> [long ago ...] Algol specified, all operators [inc standard ones
> such as "+" and "AND"] are in "user space".  You can define or
> re-define them as you choose.  Your program is embedded in an
> environment in which lots of things are defined for you, but you
> don't have to stick with the normal definitions.  It will all be
> visible in your code, so it's up to you whether you choose to
> confuse yourself or not.

I don't buy that. You will confuse yourself, and anyone who tries to
read, understand, modify or port your program. And there will be
problems mixing code that has applied different semantics to the same
syntax.

Some things I think needs to be defined by the language.

I do very little in the way of listing processing, but it's handling
mostly with user-functions, and I do not support chained comparisons.
However, they are in the standard library.

Something like your '0 < []int (a,b,c)' would be written as:

mapsv(('<'), 0, (a,b,c))

with a vector result. A further step, eg. like DAK's and() macro, would
be needed to combine those results into one:

andv(mapsv(('<'), 0, (a,b,c)))

But these work on two operands at a time. I don't know why people are
trying to compound a mildly interesting extension called 'chained
comparisons', with advanced list processing on the lines of APL.

One represents one tiny detail my language design, the other dwarfs the
whole language.

>     As previously noted, I've never felt the need to use
> "chained" compares, so I'm not going to start talking now
> about the benefits of them [for programs, as opposed to in
> mathematics, where some usages are well understood].

Here's a line from an old program I found today (to do with a Rubik cube):

if face[4] = face[5] = face[6] = face[2] = face[8] = face[1] =
face[3] then

There are several ways of doing this without using chain comparisons,
especially as all terms are indices into the same list, but when
suddenly you have to test that 7 different things have the same value,
this was the simplest way to do so at the time.

So why not?

>
> [...]
>> It's easy to add syntax in a new language. And it really isn't hard
>> in an established language.
>> Where do you think all those new features in sucessive C standards
>> come from? It is specific implementations adding extensions.
>
>     Most of them came from Algol!  Each new standard thus
> far has added something from Algol, and AFAIR nothing that is
> Algol-like has ever been taken away.

Examples? I can't think of any Algol features in C, unless you're
talking about very early days.

> [In view of discussions
> with Brian Kernighan,

I guess you didn't bring up type declaration syntax or printf formats!

>> So &&L in gnu C is special syntax to take the address of a label.
>> (Needed because labels live in their own namespace, and so &L would
>> be ambiguous.)
>
>     It's not /needed/.  It's a way of creating botches.
> Lots of early languages had label variables, and associated
> paraphernalia, and gradually mainstream languages dropped
> them.  I'm not a subscriber to "all labels are evil" [there
> was one, and an elided "GOTO", in the code I showed], but
> there is very much less need for them today than there was
> [or seemed to be] in the '50s and '60s.

A decade ago I was playing with 4 kinds of dispatch loops inside
interpreters. They were based on:

Function-tables, switches, label-tables and assembly+threaded code.

These are in increasing order of performance. For some reason which I
don't quite get, using a table of label addresses was faster than
switch. In fact, the fastest dispatch method using pure HLL code.

This required the host language to have label address and label variables.

At that time, CPython for Linux, which used gcc, relied on label-tables
to get an extra bit of performance. But CPython for Windows, which was
built with MSVC, didn't have that, because MSVC didn't have that extension.

So CPython on Windows was a bit slower than on Linux, because someone
decided that label pointers weren't worth having.

>> Eg. 'break' being overloaded; a*b meaning multiply a by b, OR declare
>> variable b of type 'pointer to a'.
>
>     That's the sort of thing that happens when a private
> language goes public before it is properly defined, and
> without proper critical scrutiny.

Lots of opportunity to get C fixed. But people who like C aren't
interested; every terrible misfeature is really a blessing!

In the 70s, Fortran also had formats of sorts for printing values. The
lastest Fortran however lets you write:

print *, a, b, c

Meanwhile C still requires you to do:

printf("%lld %f %u\n", a, b, c);

or something along those lines, because it depends on the types of a, b
and c. Some languages are better at moving on!

>>>      When you say you've done it, you mean you've tweaked your
>>> compiler.  More important from my PoV is to explain it to users,
>>> inc re-writing the "User Manual" to include the new syntax.
>> That would just be a Note: you can only mix '= < <=' or '= > >='.
>
>     Note again that in Algol "chained" comparisons, if
> you choose to use them, are entirely private grief, and no
> change to any syntax is required.

The grief would be in having to write:

IF a=b AND b=c AND c=d THEN

or, in devising those operator overloads, which still doesn't give you a
nice syntax, and will restrict the types it will work on, instead of
just writing:

if a=b=c=d then

On 2021-10-31 11:52, Bart wrote:

> Here's a line from an old program I found today (to do with a Rubik cube):
>
>   if face[4] = face[5] = face[6] = face[2] = face[8] = face[1] =
> face[3] then
>
> There are several ways of doing this without using chain comparisons,
> especially as all terms are indices into the same list, but when
> suddenly you have to test that 7 different things have the same value,
> this was the simplest way to do so at the time.
>
> So why not?

Because it is very marginal and for a sane person suggests a typo error.
A cleaner way would to define a function like

All_Same (List, Ignore) -- Compare list elements ignoring one

Otherwise, you can do that in Ada, no problem:
----------------------------------------------
type Chained_Result is record
Partial : Boolean;
Tail : Integer;
end record;
function "=" (Left, Right : Integer) return Chained_Result is
begin
return (Left = Right, Right);
end "=";
function "=" (Left : Chained_Result; Right : Integer)
return Chained_Result is
begin
return (Left.Partial and then Left.Tail = Right, Right);
end "=";
function "=" (Left : Chained_Result; Right : Integer)
return Boolean is
begin
return (Left.Partial and then Left.Tail = Right);
end "=";
----------------------------------------------

That is all you need to do this:

a : Integer := 1;
b : Integer := 2;
c : Integer := 3;
begin
Put_Line (Boolean'Image ((a = b) = c));

will print

FALSE

Note, the parenthesis. These are a purely syntax requirement, not
because the language could not handle:

a = b = c

It would be all OK, but relational operators sharing operands are not
allowed in Ada. You must separate them. Other examples are

a or b and c
-a**b
a**b**c

etc. Ada does require you to remember 20+ levels of precedence.

And yes, you could make the above a generic package to work with any
integer type.

The problem of handling chained comparisons syntactically (as a macro)
rather than typed within the normal/sane syntax is that you will have
numerous barriers the parser could not handle. Starting with parenthesis:

a = (b) = c

These you could work around. But what about chaining mixed types:

b := (x, y, z); -- List of elements

a = b = c

It is easy to handle in Ada since you have proper objects for which you
can define the equality operator you wanted. Macros cannot do that.

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

On 31/10/2021 11:45, Dmitry A. Kazakov wrote:
> On 2021-10-31 11:52, Bart wrote:
>
>> Here's a line from an old program I found today (to do with a Rubik
>> cube):
>>
>>    if face[4] = face[5] = face[6] = face[2] = face[8] = face[1] =
>> face[3] then
>>
>> There are several ways of doing this without using chain comparisons,
>> especially as all terms are indices into the same list, but when
>> suddenly you have to test that 7 different things have the same value,
>> this was the simplest way to do so at the time.
>>
>> So why not?
>
> Because it is very marginal and for a sane person suggests a typo error.

How about an example like this:

if hsample2 = vsample2 = hsample3 = vsample3 and
hsample1 <= 2 and vsample1 <=2 then

(The last part of that looks like a candicate for one of your (hsample1,
vsample2) <= 2 ideas. But most likely syntaxes end up looking worse than
the original.)

> A cleaner way would to define a function like
>    All_Same (List, Ignore)  -- Compare list elements ignoring one

This is overkill for just 3 (or 4) elements instead of two.

100 elements, then yes you'd use list processing and other techniques,
since the elements wouldn't be individually enumerated anyway.

> Otherwise, you can do that in Ada, no problem:

The problem is that this is all quite complicated, and requires some
extra skills, especially if you want to work with any types.

I favour building it into a language. That also requires special skills,
but that is only required of the implementer.

My version of it probably added 100 lines of straightforwards code to
the static code compiler (and 60 to the dynamic one). It also works for
arbitrary types and other comparison operators.

You don't need overload features, nor do you have implement the feature
yourself.

> ----------------------------------------------
>    type Chained_Result is record
>       Partial : Boolean;
>       Tail    : Integer;
>    end record;
>    function "=" (Left, Right : Integer) return Chained_Result is
>    begin
>       return (Left = Right, Right);
>    end "=";
>    function "=" (Left : Chained_Result; Right : Integer)
>       return Chained_Result is
>    begin
>       return (Left.Partial and then Left.Tail = Right, Right);
>    end "=";
>    function "=" (Left : Chained_Result; Right : Integer)
>       return Boolean is
>    begin
>       return (Left.Partial and then Left.Tail = Right);
>    end "=";
> ----------------------------------------------
>
> That is all you need to do this:
>
>    a : Integer := 1;
>    b : Integer := 2;
>    c : Integer := 3;
> begin
>    Put_Line (Boolean'Image ((a = b) = c));
>
> will print
>
>    FALSE
>
> Note, the parenthesis. These are a purely syntax requirement, not
> because the language could not handle:
>
>    a = b = c
>
> It would be all OK, but relational operators sharing operands are not
> allowed in Ada. You must separate them. Other examples are
>
>    a or b and c
>   -a**b
>    a**b**c
>
> etc. Ada does require you to remember 20+ levels of precedence.
>
> And yes, you could make the above a generic package to work with any
> integer type.
>
> The problem of handling chained comparisons syntactically (as a macro)
> rather than typed within the normal/sane syntax is that you will have
> numerous barriers the parser could not handle. Starting with parenthesis:
>
>    a = (b) = c
>
> These you could work around. But what about chaining mixed types:
>
>   b := (x, y, z); -- List of elements
>
>   a = b = c
>
> It is easy to handle in Ada since you have proper objects for which you
> can define the equality operator you wanted. Macros cannot do that.
>

On 2021-10-31 15:32, Bart wrote:
> On 31/10/2021 11:45, Dmitry A. Kazakov wrote:
>> On 2021-10-31 11:52, Bart wrote:
>>
>>> Here's a line from an old program I found today (to do with a Rubik
>>> cube):
>>>
>>>    if face[4] = face[5] = face[6] = face[2] = face[8] = face[1] =
>>> face[3] then
>>>
>>> There are several ways of doing this without using chain comparisons,
>>> especially as all terms are indices into the same list, but when
>>> suddenly you have to test that 7 different things have the same
>>> value, this was the simplest way to do so at the time.
>>>
>>> So why not?
>>
>> Because it is very marginal and for a sane person suggests a typo error.
>
> How about an example like this:
>
>     if hsample2 = vsample2 = hsample3 = vsample3 and
>        hsample1 <= 2 and vsample1 <=2 then
>
> (The last part of that looks like a candicate for one of your (hsample1,
> vsample2) <= 2 ideas. But most likely syntaxes end up looking worse than
> the original.)

I would split that into several tests commenting on what is going on.
Long formulae are subject of careful revision. Mathematically, the above
looks like an expression of some sort of symmetry. Surely the problem
space has a term for that and I expect to see it in the program, e.g. as
a function call. That is the difference between construed examples and
real-life programs.

> The problem is that this is all quite complicated, and requires some
> extra skills, especially if you want to work with any types.

If you do that frequently you have the skill, if you do not, then you do
not need it.

> I favour building it into a language. That also requires special skills,
> but that is only required of the implementer.

No, it makes the language unsafe. Because the chances are 99% that a=b=c
is just an error. So I prefer the language rejecting it straight away
without consideration of any types or operations involved.

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

On 31/10/2021 15:43, Dmitry A. Kazakov wrote:
> On 2021-10-31 15:32, Bart wrote:
>> On 31/10/2021 11:45, Dmitry A. Kazakov wrote:
>>> On 2021-10-31 11:52, Bart wrote:
>>>
>>>> Here's a line from an old program I found today (to do with a Rubik
>>>> cube):
>>>>
>>>>    if face[4] = face[5] = face[6] = face[2] = face[8] = face[1] =
>>>> face[3] then
>>>>
>>>> There are several ways of doing this without using chain
>>>> comparisons, especially as all terms are indices into the same list,
>>>> but when suddenly you have to test that 7 different things have the
>>>> same value, this was the simplest way to do so at the time.
>>>>
>>>> So why not?
>>>
>>> Because it is very marginal and for a sane person suggests a typo error.
>>
>> How about an example like this:
>>
>>      if hsample2 = vsample2 = hsample3 = vsample3 and
>>         hsample1 <= 2 and vsample1 <=2 then
>>
>> (The last part of that looks like a candicate for one of your
>> (hsample1, vsample2) <= 2 ideas. But most likely syntaxes end up
>> looking worse than the original.)
>
> I would split that into several tests commenting on what is going on.
> Long formulae are subject of careful revision. Mathematically, the above
> looks like an expression of some sort of symmetry. Surely the problem
> space has a term for that and I expect to see it in the program, e.g. as
> a function call. That is the difference between construed examples and
> real-life programs.

Below is the context for that example.

This checks a jpeg file configuration before choosing a suitable handler
for the rest of the file.

h/vsample1/2/3 are sampling rates in hoz/vert for Y, U and V channels;
the latter two must match each other.

The comptype codes 1/2/3 mean Y/U/V, and this tests they are in that
order and for those channels.

Here I only handle 3 channels, Y/U/V, with certain sampling combinations.

---------------------------
function loadscan(fs,hdr)=
initbitstream(fs)

(vsample1,vsample2,vsample3) := hdr.vsample
(hsample1,hsample2,hsample3) := hdr.hsample
(comptype1,comptype2,comptype3) := hdr.comptype

pimage := nil
case hdr.ncomponents
when 1 then
abort("loadmono")
when 3 then
if comptype1<>1 or comptype2<>2 or comptype3<>3 then
abort("comptype?")
fi
if hsample2=vsample2=hsample3=vsample3 and
hsample1<=2 and vsample1<=2 then
pimage := loadcolour(fs,hdr,hsample1,vsample1)
else
println hsample1,vsample1,hsample2,vsample2,hsample3,vsample3
abort("Unknown sampling")
fi
else
abort("ncomp")
esac

return pimage
end

On 2021-10-31 17:11, Bart wrote:
> On 31/10/2021 15:43, Dmitry A. Kazakov wrote:

> Below is the context for that example.
>
> This checks a jpeg file configuration before choosing a suitable handler
> for the rest of the file.
>
> h/vsample1/2/3 are sampling rates in hoz/vert for Y, U and V channels;
> the latter two must match each other.

Then you do need separate checks in order to give meaningful error
message on what exactly is wrong. Unless you missed something, because
it is unusual to have that much redundancy without any use.

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

On 31/10/2021 10:52, Bart wrote:
[I wrote, re Algol:]
>> [...] Your program is embedded in an
>> environment in which lots of things are defined for you, but you
>> don't have to stick with the normal definitions.  It will all be
>> visible in your code, so it's up to you whether you choose to
>> confuse yourself or not.
> I don't buy that. You will confuse yourself, and anyone who tries to
> read, understand, modify or port your program. And there will be
> problems mixing code that has applied different semantics to the same
> syntax.

With respect, that's just silly. You aren't forced to define
or use your own operators; the standard ones are broadly the same as
those in every other normal language. So are the priorities, and the
standard functions. If a skilled programmer /chooses/ to provide
some new operators [and aside from deliberate attempts to obfuscate
for competition purposes, and such like], then it is to make code
/clearer/. For example, if you happen to be doing matrix algebra,
it is likely to be much clearer if you write new operators rather
than new functions, so that you can reproduce quite closely normal
mathematical notations. Code will only be "mixed" if several
people write different bits of a project /without/ agreeing the
specifications of their own bits; that is a problem for /any/
large project, and nothing to do with Algol. You can write code
that is difficult to "read, understand, modify or port" in any
non-trivial language; again, nothing special about Algol, more to
do with unskilled programmers following dubious practices.

> Some things I think needs to be defined by the language.

Again, the things that it is normal to define are perfectly
well defined in Algol. It's just easier to use existing syntax on
new operators and functions than it is in most other languages.

> I do very little in the way of listing processing, but it's handling
> mostly with user-functions, and I do not support chained comparisons.
> However, they are in the standard library.

If you don't "support" them then what do you mean by "in the
standard library"? Is it not your own language, entirely under your
own control and providing what [and only what] you yourself support?

> Something like your '0 < []int (a,b,c)' would be written as:
> mapsv(('<'), 0, (a,b,c))
> with a vector result.

Is that supposed to be clearer? What are the specification
for your "mapsv" function, and what am I supposed to do if I want
something slightly different? [My Algol snippet was entirely user-
written, and could easily be tweaked any way I chose, all there and
visible in the code. If you want something different, take it and
tweak it your own way -- entirely up to you.]

>> [...] Each new [C] standard thus
>> far has added something from Algol, and AFAIR nothing that is
>> Algol-like has ever been taken away.
> Examples? I can't think of any Algol features in C, unless you're
> talking about very early days.

Early days were important for C, as when there was only K&R
C, and C was "what DMR's compiler does", it was easy to change the
language, and there are a fair number of changes between the first
versions and 7th Edition Unix. More recently, they have added
type "Bool", dynamic arrays, stronger typing, parallel processing,
complex numbers, anonymous structures and unions, possible bounds
checking, "long long" types and related ideas, mixed code and
declarations, better string handling, and doubtless other things
I've forgotten.

[...]
>>> Eg. 'break' being overloaded; a*b meaning multiply a by b, OR declare
>>> variable b of type 'pointer to a'.
>>      That's the sort of thing that happens when a private
>> language goes public before it is properly defined, and
>> without proper critical scrutiny.
> Lots of opportunity to get C fixed. But people who like C aren't
> interested; every terrible misfeature is really a blessing!

You can't fix "break" or "a*b"; by the time of 7th Edition,
it was already too late, there were thousands of users and hundreds of
thousands of programs, and too much would have broken if you changed
such fundamental syntax. So almost all changes since have been either
new facilities that could not have been written in correct earlier C,
or a tightening up on things that were previously ill-defined. Again,
this is a difference between private languages and major ones. If you
want a reasonable change in C, the way to achieve that is to implement
it in "gcc" or similar, show that it works without breaking anything,
and put it to the committee. Most grumblies aren't prepared to put in
the hard work and/or don't understand the problems with their ideas.

[...]
>>      Note again that in Algol "chained" comparisons, if
>> you choose to use them, are entirely private grief, and no
>> change to any syntax is required.
> The grief would be in having to write:
>   IF a=b AND b=c AND c=d THEN
> or, in devising those operator overloads, which still doesn't give
> you a nice syntax, and will restrict the types it will work on,
> instead of just writing:
>   if a=b=c=d then

Allowing "a=b=c=d" shows that "a=b" means one thing if it
is "stand alone" and something quite different if it is a left
operand. You're very good at saying "my language allows XXX" for
all manner of interesting and perhaps even desirable "XXX", but
it's at the expense of specifying exactly what the related syntax
and semantics are. In Algol, expressions are parsed by the usual
rules of precedence and [L->R] associativity, after which "a o b"
for any operands "a" and "b" and any operator "o" means exactly
the same as "f(a,b)" where "f" is a function with two parameters
of the same types as those of "o" and the same code body as that
of "o", all completely visible in the RR plus your own code.
What's the corresponding rule in your language?

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Hummel

On 01/11/2021 23:00, Andy Walker wrote:
> On 31/10/2021 10:52, Bart wrote:
> [I wrote, re Algol:]
>>> [...] Your program is embedded in an
>>> environment in which lots of things are defined for you, but you
>>> don't have to stick with the normal definitions.  It will all be
>>> visible in your code, so it's up to you whether you choose to
>>> confuse yourself or not.
>> I don't buy that. You will confuse yourself, and anyone who tries to
>> read, understand, modify or port your program. And there will be
>> problems mixing code that has applied different semantics to the same
>> syntax.
>
>     With respect, that's just silly.  You aren't forced to define
> or use your own operators;  the standard ones are broadly the same as
> those in every other normal language.  So are the priorities, and the
> standard functions.  If a skilled programmer /chooses/ to provide
> some new operators [and aside from deliberate attempts to obfuscate
> for competition purposes, and such like], then it is to make code
> /clearer/.

Sorry, but I had a lot of trouble understanding your A68 example. For
example, part of it involved arrays, which I thought was some extra
ability you'd thrown in, but I think now may actually be necessary to
implement that feature. [I still don't know...]

It reminds me of posts in comp.lang.c where people claim some new
feature is not necessary. because it so 'straightforward' to
half-implement some terrible version of it via impenetrable
meta-programming.

> For example, if you happen to be doing matrix algebra,
> it is likely to be much clearer if you write new operators rather
> than new functions, so that you can reproduce quite closely normal
> mathematical notations.

It could well be clearer, AFTER you've had to implement it via code that
is a lot less clearer than ordinary user-code.

(My first scripting language had application-specific types including 3D
transformation matrices and 3D points. There, if A and B are matrices,
and P is a point, then:

C := A*B # multiples matrices
Q := C*P # use C to transform P

/That/ was clear, with the bonus that the user didn't need to implement
a big chunk of the language themself!)

> Code will only be "mixed" if several
> people write different bits of a project /without/ agreeing the
> specifications of their own bits;  that is a problem for /any/
> large project, and nothing to do with Algol.  You can write code
> that is difficult to "read, understand, modify or port" in any
> non-trivial language;  again, nothing special about Algol, more to
> do with unskilled programmers following dubious practices.

If the effect is to create lots of mini, overlapping dialects or
extensions, then that is a problem. There will be assorted custom
preludes or drag in too.

>> I do very little in the way of listing processing, but it's handling
>> mostly with user-functions, and I do not support chained comparisons.
>> However, they are in the standard library.
>
>     If you don't "support" them then what do you mean by "in the
> standard library"?

They are implemented as user-functions which are placed in a library
that comes with the language.

>> Something like your '0 < []int (a,b,c)' would be written as:
>>    mapsv(('<'), 0, (a,b,c))
>> with a vector result.
>
>     Is that supposed to be clearer?

I'm not pretending my language properly supports list operations. That
would be a very different kind of language.

My mapsv is clearer for me since the 's' and 'v' indicate that it takes
a 'scalar' and a 'vector' operand. ('scalar' here just means it is
treated as a single value, and 'vector' that it is a multiple value.)

Then the rules for that removes any confusion about the result:

mapsv(op, A, B): scalar op vector -> vector

> What are the specification
> for your "mapsv" function, and what am I supposed to do if I want
> something slightly different?  [My Algol snippet was entirely user-
> written, and could easily be tweaked any way I chose, all there and
> visible in the code.  If you want something different, take it and
> tweak it your own way -- entirely up to you.]

-------------------------
global function mapsv(op,as,b)=
#Apply op or function between elements of single value as and vector b
c::=makeempty(b)
forall i,x in b do
c[i]:=mapss(op,as,x)
od
return c
end
-------------------------

(Hmm, maybe 's' stands for 'single' not 'vector'!)

mapss is an actual built-in function which is awkward in user-code,
since 'op' can be any built-in binary op, or any user-function taking
two parameter.

The language has poorly developed operator overloading which is little used.

I don't think you can write my mapss() function in Algol68. Example:

a:=12
b:=20

println mapss( (random(1..4)|(+), (-), (*)| (/)), a, b)

Output is 240.

>> Examples? I can't think of any Algol features in C, unless you're
>> talking about very early days.
>
>     Early days were important for C, as when there was only K&R
> C, and C was "what DMR's compiler does", it was easy to change the
> language, and there are a fair number of changes between the first
> versions and 7th Edition Unix.  More recently, they have added
> type "Bool", dynamic arrays, stronger typing, parallel processing,
> complex numbers, anonymous structures and unions, possible bounds
> checking, "long long" types and related ideas, mixed code and
> declarations, better string handling, and doubtless other things
> I've forgotten.

OK, but its implementations of those are crude and remain low level.

People mainly use them to write poorer code that is harder to follow.

> You can't fix "break" or "a*b";  by the time of 7th Edition,
> it was already too late,

It's never too late. An alternate to 'break' could have been introduced
for switch, eg. have both 'break' and 'breaksw'; eventually only
'breaksw' is allowed, and 'break' is an error. Then, further along,
'break' inside switch is allowed to be used for loop-break.

However, try taking a program from 1980 and try compiling it now.
Actually, take a program from 2021 and try building it with two
different compilers.

>> The grief would be in having to write:
>>    IF a=b AND b=c AND c=d THEN
>> or, in devising those operator overloads, which still doesn't give
>> you a nice syntax, and will restrict the types it will work on,
>> instead of just writing:
>>    if a=b=c=d then
>
>     Allowing "a=b=c=d" shows that "a=b" means one thing if it
> is "stand alone" and something quite different if it is a left
> operand.  You're very good at saying "my language allows XXX" for
> all manner of interesting and perhaps even desirable "XXX", but
> it's at the expense of specifying exactly what the related syntax
> and semantics are.

I copied the feature from Python. You'd need to ask Guido what it means!

> In Algol, expressions are parsed by the usual
> rules of precedence and [L->R] associativity, after which "a o b"
> for any operands "a" and "b" and any operator "o" means exactly
> the same as "f(a,b)" where "f" is a function with two parameters
> of the same types as those of "o" and the same code body as that
> of "o", all completely visible in the RR plus your own code.
> What's the corresponding rule in your language?

If I write:

A = B = C

in static code, then it works something like this:

* The dominant type of A, B, C is determined

* A, B, C are converted to that type as needed, as values A', B', C'
(This is for numeric types; "=" also works for exactly compatible
arbitrary types with no conversions applied)

* The expression returns True when A', B', C' have identical values

On 02/11/2021 01:38, Bart wrote:
> On 01/11/2021 23:00, Andy Walker wrote:

>>> Something like your '0 < []int (a,b,c)' would be written as:
>>>    mapsv(('<'), 0, (a,b,c))
>>> with a vector result.
>>
>>      Is that supposed to be clearer?
>
> I'm not pretending my language properly supports list operations. That
> would be a very different kind of language.
>
> My mapsv is clearer for me since the 's' and 'v' indicate that it takes
> a 'scalar' and a 'vector' operand. ('scalar' here just means it is
> treated as a single value, and 'vector' that it is a multiple value.)

I think this is how it works in the 'K' programming language (a
derivative of APL):

0 < a b c

This prodouces a vector. To combine the bools into a single value, is
possibly done like this (I don't have a version to try):

& 0 < a b c

I don't know about precedences (except it works right to left iirc). On
mine, it would not be hard to define 'and' (&) to work as a unary
operator, which is expected to be a list:

and (a, b, c)
and L # where L is a list

Doing this for "<" is trickier:

0 < (a, b, c)

because while this example seems obvious, it could also look like this:

x < L

Here, x could be "C" and L could be "ABCDE", so that "C" < "ABCDE" is
false (comparing two strings). But you might want L to be treated as a
list of one-character strings, so that the result is (0, 0, 0, 1, 1).

I don't know how K sorts this out. Using my mapsv however:

x := "C"
L := "ABCDEF"
print mapsv((<), x, L)

This correctly shows (0,0,0,1,1). So it might be ugly, but you have
better confidence that it does what you want.

The ugliness can be mitigated a little via a macro:

macro lessv(a,b) = mapsv((<),a,b)

print lessv(x, L)

On 27/10/2021 01:15, Bart wrote:
> On 23/10/2021 15:39, James Harris wrote:
>
>
>> 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.
>
> If you don't have chained comparisons, then you have to decide what a <
> b < c or a = b = c mean. Where there isn't an intuitive alternative
> meaning, then you might as well use that syntax to allow chains.

Good point. Should it even be possible to apply magnitude comparisons
(i.e. those including < and > symbols) to boolean values?

Assuming it should be, if one wanted to evaluate

a < b

and then ask if the boolean result was 'less than' c, without chained
comparisons it would be as simple as

a < b < c

but how would one express that in a language which supported chained
comparisons? I think my preference would be

bool(a < b) < c

where bool() would break up the comparison chain by having the form of a
function call but would have no effect on the value. That would work on
your equals example, too: either of

bool(a == b) == c
a == bool(b == c)

There's another potential problem with chained comparisons, though. Consider

a < b < c < d

What if a programmer wanted to evaluate the b < c part first?

>
> But you might want to restrict it so that the sequence of comparisons
> are either all from (< <= =) or (> >= =).
>
> So that if you were to plot the numeric values of A op B op C for
> example when the result is True, the gradient would always be either >=
> 0 or <= 0; never mixed; ie no ups then downs.
>
> (Which also allows you to infer the relationship of A and C).

When you see a chained comparison do you try to read it as a single
expression? Yes, one can if the operators are all in the same direction,
as you indicate, but maybe in general it's better to read the
comparisons as individual operations.

>
> Then, x < y > z would not be allowed (it's too hard to grok);

Is it really any harder to grok than

x < y && y > z

and if so, why not just read the former as the latter?

> neither
> would x != y != z, even if it is equivalent to:
>
>   x != y and y != z
>
> (That is better written as y != x and y != z; I would write it as y not
> in [x, z])

It would seem inconsistent to allow

a == b == c

and yet prohibit

a != b != c

--
James Harris