Message-ID:

The heart is not a logical organ. -- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

devel / comp.lang.misc / Re: Chained comparisons A < B < C

Re: Chained comparisons A < B < C

<sm8soc$9fq$1@dont-email.me>

https://www.rocksolidbbs.com/devel/article-flat.php?id=1156&group=comp.lang.misc#1156

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: james.harris.1@gmail.com (James Harris)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm3cn3$iti$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 7 Nov 2021 15:52:44 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="c0268972214f514e8c33e41711c1b8cd";
logging-data="9722"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX192znRuvYKqhhAS3KsnyfKb14j1xHYvxOY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:trah02ZoqnAbmzYW7vZx38ntFP0=
In-Reply-To: <sm3cn3$iti$1@dont-email.me>
Content-Language: en-GB

by: James Harris - Sun, 7 Nov 2021 15:52 UTC

On 05/11/2021 13:48, Bart wrote:

....

>
> I see several levels of user-defined/overloaded operators:

....

That (now snipped) looks like an extensive write-up on operator
overloading options and a good springboard into the topic. The thing is,
this discussion is about chained comparisons. Why didn't you start a new
thread?

--
James Harris

Re: Chained comparisons A < B < C

<sm93sn$l0j$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1157&group=comp.lang.misc#1157

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: james.harris.1@gmail.com (James Harris)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<slubit$st2$1@dont-email.me> <sluic4$i95$1@dont-email.me>
<slut0q$6om$1@dont-email.me> <slv520$vt4$1@dont-email.me>
<sm0crl$sf2$1@dont-email.me> <sm0r3k$2ea$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 7 Nov 2021 17:54:31 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="c0268972214f514e8c33e41711c1b8cd";
logging-data="21523"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Qr2PqMid2xMbJsRjCY2v1lYCyAeefuXY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:93fyycL+w3ZLSpkbzXum7JosJJw=
In-Reply-To: <sm0r3k$2ea$1@dont-email.me>
Content-Language: en-GB

by: James Harris - Sun, 7 Nov 2021 17:54 UTC

On 04/11/2021 14:35, Bart wrote:
> On 04/11/2021 10:32, James Harris wrote:
>> On 03/11/2021 23:13, Bart wrote:

....

>> a >
>> should evaluate a then b, then if a > < c is true evaluate d, then if c < d then the whole expression would
>> be true. Do you see it differently?
>
> Yes, that's what I do. 'if a 
> push t.start.a i64
> push t.start.b i64
> jumpge #4 i64
> push t.start.b i64
> push t.start.c i64
> jumpge #4 i64
> push t.start.c i64
> push t.start.d i64
> jumpge #4 i64
> # <body of if>
> #4:

Looks good to me.

....

>>> You can't use a chain which implies a particular order,
>>> short-circuiting in a similar manner to 'and' and 'or':
>>
>> Why not?
>
> Because in the case of 'a<b<c<d', which may exit early when a>=b, c and
> d would not get evaluated. But you're saying you want the programmer to
> tell the language they should be evaluated first anyway?

No. I am querying whether parens in

a < (b < c) < d

should be allowed to specify the evaluation of b < c first while
maintaining the chain. You could think of the language doing that for
utility and consistency. On the utility of it the programmer might want
to encode

if b < c and a < b and c < d

thereby not evaluating the rest if "b < c", i.e. evaluating the b < c
part first. On the consistency of it it would be similar to

a - (b - c) - d

where b - c would effectively be evaluated first, e.g. to avoid
overflow, albeit that there's no shortcutting going on.

....

>> In practice a compiler /could/ evaluate operands in a different order
>> where it could be sure that that would not affect the semantics -
>> which would be most cases.
>
> If it doesn't affect the semantics, then why would a programmer want a
> different order? It can only be for different results.
>
> For faster code? That's the compiler's job!

As an example,

F(A(), B())

I define that to evaluate A() before B(). If the internals of A and B
are unknown then that's exactly what the compiler would have to emit
code to do. As you will be aware, that can be slightly awkward when the
call stack needs to be constructed right-to-left.

Therefore what I was saying was that when the compiler can tell that
there's no conflict (e.g. A() has no side effects) it can evaluate B()
then A(). In particular, in something like

F(X, Y)

F(3, 2)

or even more (i.e. in most cases) evaluation can be done R-L while
maintaining the semantics of L-R evaluation.

>
>>>
>>> > (((a < b) < c) < d)
>>>
>>> This doesn't guaranteed that a>> it does (a<b) and c, not a and (b<c).
>>>
>>> It also means that this is not a comparison chain.
>>>
>>
>> IYO...!
>
> No, it's just not a chain. Unless you want to argue about the difference
> between a linked list, a binary tree, and a degenerate(?) binary tree
> which is more of a vertical linked list.

Interesting point of disagreement. I would say that while you personally
may not parse it as a chain that doesn't necessarily stop it being one!

>
> My chain of comparison ops is equivalent to a linked list. Any other
> shape, is not the same thing. Not in my language, because I say so!

:-)

--
James Harris

Re: Chained comparisons A < B < C

<sm9emp$uud$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1158&group=comp.lang.misc#1158

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm3cn3$iti$1@dont-email.me>
<sm8soc$9fq$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 7 Nov 2021 20:59:05 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ae9bf66fb5f6708916e003e703a29f5b";
logging-data="31693"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18IIO1XZa5tb9pB8Ys77up6hXSxcQz/qVU="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Cancel-Lock: sha1:7DR28TmSt42t15nyhz+Md3hw9N0=
In-Reply-To: <sm8soc$9fq$1@dont-email.me>

by: Bart - Sun, 7 Nov 2021 20:59 UTC

On 07/11/2021 15:52, James Harris wrote:
> On 05/11/2021 13:48, Bart wrote:
>
> ...
>
>>
>> I see several levels of user-defined/overloaded operators:
>
> ...
>
> That (now snipped) looks like an extensive write-up on operator
> overloading options and a good springboard into the topic. The thing is,
> this discussion is about chained comparisons. Why didn't you start a new
> thread?

Could do, but I've not much left to say.

I think I made it clear I'm not keen on user-defined operators, of
either kind, as there are too many issues with few benefits.

(Besides, I find it easy enough to create new, built-in operators in my
own implementations, when I need to.)

I'm OK with overloading existing operators, although I've done very
little with that.

On Sun, 5 Sep 2021 11:50:18 +0100
James Harris <james.harris.1@gmail.com> 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

Ok.

> means that B is between A and C?

Why does this have something to do with B? ...

I.e., you seem to think it's the result of:

(A < B) && (B < C)

Charles thinks it's generally parsed as:

(A < B) < C

Whereas, I would've assumed it had something to do with A:

A < (B < C)

In other words, I generally assume that the assigned to variable, or
the intended final comparison of a chained sequence, is on the left, as
in C or BASIC etc, albeit there is no explicit assignment operator in
your chained comparison.

> Or should a programmer have to write
>
> A 
> ?

I think the issue is how you specify which comparison or comparisons or
variable you want as the result, as this will determine the order of
the operations. Do you let the parsing rules decide? e.g.,
left-to-right or right-to-left? Do you define which variable must be
returned? e.g., leftmost, rightmost, middle?
> 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 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 above yields a boolean) or to allow the above kind of chaining where
> a meaning is attributed to a succession of such operators?

I generally don't like chaining, even in C, because a) it can be
confusing as to what is intended by the programmer, and b) may require
the programmer to memorize esoteric rules they will forget. When they
do, you get parens slapped around everything to control the parsing
order, so the code looks like LISP.

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

....

--
Is this the year that Oregon ceases to exist?

On Mon, 6 Sep 2021 23:24:47 +0200
David Brown <david.brown@hesbynett.no> wrote:

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

Yes, and that's why C programmers usually use the totally f'd up style,
where the braces are completely out of alignment with each other, which
reliably and consistently leads to readability issues in C from
erroneous indentation, especially after trivial editing.

When instead, they should use the logical and rational and obviously
significantly more READABLE style of a C novice, where the braces are
column aligned, whereby indentation errors are substantially easier to
identify.

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

Disagree.

The spaces make it significantly harder to read for me.

--
Is this the year that Oregon ceases to exist?

On 08/11/2021 01:25, Rod Pemberton wrote:
> On Sun, 5 Sep 2021 11:50:18 +0100
> James Harris <james.harris.1@gmail.com> 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 >
>
> Ok.
>
>> means that B is between A and C?
>
> Why does this have something to do with B? ...
>
> I.e., you seem to think it's the result of:
>
> (A < B) && (B < C)

That's the suggestion. And it is a suggestion. It's not meant to be
about parsing an existing language!

>
> Charles thinks it's generally parsed as:
>
> (A < B) < C
>
> Whereas, I would've assumed it had something to do with A:
>
> A < (B < C)
>
> In other words, I generally assume that the assigned to variable, or
> the intended final comparison of a chained sequence, is on the left, as
> in C or BASIC etc, albeit there is no explicit assignment operator in
> your chained comparison.

That's a bit odd. There's no assignment at all. It might make it clearer
to consider it in context of IF statements:

if A W then print "V is highest of the three variables"

--
James Harris

Re: Chained comparisons A < B < C

<smcdrl$s1e$1@gioia.aioe.org>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1210&group=comp.lang.misc#1210

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!aioe.org!hzH9W6jJqCaoslGwVpYj5g.user.46.165.242.75.POSTED!not-for-mail
From: anw@cuboid.co.uk (Andy Walker)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="28718"; posting-host="hzH9W6jJqCaoslGwVpYj5g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB

by: Andy Walker - Tue, 9 Nov 2021 00:03 UTC

On 07/11/2021 15:49, James Harris wrote:
[I wrote:]
>> Sorry, but why do you think that creating a new operator
>> is [other things being equal] a worse practice than creating a
>> new function with the same parameters, code, specification, etc?
>> What demons are you fighting?
> Fighting demons may describe your approach to problem solving if you
> are doing so by defining brand new operator symbols but I suggest
> that there are specific problems with doing so:

I wasn't talking about problem solving but about a weird
frame of mind in which you are happy for people to write

proc wertyuiop = (int a, b) bool: a > b;

[adjust to whatever your preferred syntax for procedure declarations
is], but

op wertyuiop = (int a, b) bool: a > b;

is a no-no? In any given case, you can decide for yourself whether
the names are meaningful; it's obviously [IMO] better if they are,
but I don't know of any language in which identifiers are allowed
or banned on that basis.

> 1. While well-known operators are enunciable (e.g. := can be read as
> "becomes" and >= can be read as "is greater than or equal to") in a
> way that reflects their meaning that's not true of new ones. For
> example, how would you read any of these:
> @:
> #~
> %!?

In Algol? None of those are potential operators: "@", ":",
"#" and "~" are already in the syntax ["@" is for slices, ":" for
labels and similar, "#" for comments and "~" is a skip]; operators
are one or two symbols from an relatively uninteresting list of the
usual suspects, optionally followed by ":=" or "=:", so "%!?" is
too long. As for enunciation, this is, as usual, a matter of
trusting the programmer to be sensible. The fact that it is
possible to write obscure code is not a challenge for people to
do so! OTOH, APL is that-away -->.

> 2. While the meaning of the new composite symbol may be logical to
> the person who makes it up its appearance can be meaningless to
> someone else. For example,
> >=<

Again, this is not a legal A68 operator. If it had been,
then the same applies -- programmers should write readable code.
But it is always possible that they are following the symbolisms
used in, say, a physics paper, in which case it becomes sensible
for both programmers and [informed] readers.

[...]
> 3. You may not like to hear criticism of Algol and I wouldn't
> criticise it unnecessarily

The [often ignorant] criticism here is as naught compared
with the [often informed] criticism of Algol 68 when it first
came out. Some of that resulted in the improvements of the
Revised Report; some of it resulted in Pascal [be careful what
you wish for!].

> but didn't you recently show code in which
> Algol allows programmers to define the precedence of new operators?

It not merely allows, it requires that for /new/ dyadic
operators. How else could a compiler know what precedence to
use?

> If so, that also helps to make expressions unreadable for the reasons
> I set out before, i.e. that in an expression such as
> a or b #? c + d
> there is no clue as to how #? it will be parsed relative to the
> operators on either side of it.

Again, you're seeing gremlins where none exist. IRL,
bad programmers write unreadable and incompetent code in any
language [even Basic], and good programmers write readable
and competent code in any language [even (deleted)]. But in
return, the reader has to make the effort to become familiar
with the language.

[...]
>> It tells the programmer exactly as much as an unfamiliar
>> function name. Whether you see "a >=< b" or "myweirdfunc (a, b)"
>> you're going to have to go to the defining occurrence of the
>> operator/function to find out what is going on [same in both
>> cases!].
> I would say two things to that. First, the best approach is for a
> language to come with a comprehensive standard library which provides
> common (and not so common) data structures, operations and
> algorithms. That saves many different programmers inventing the same
> solutions to problems and calling them by different names thus making
> code easier to read for everyone.

Within reason, these things don't belong in the language
/definition/. It's open to commercial companies or academe to
provide useful libraries [eg, the NAG library of high-quality NA
routines]. You can't expect what is usually a small group of
programmers to implement high-quality NA /and/ stats /and/
celestial mechanics /and/ number theory /and/ cryptography /and/
.... as well as being competent enough to design and implement a
good language. After that, you have the problem of information
overload. Language definitions are already too big! It takes
over 600 pages to describe standard C [not a massive language];
if you add a couple of hundred more pages to describe dozens of
pre-defined types, scores of relevant operators, hundreds of
interesting functions, people will just switch off and not
bother to read them. [Unix/Linux has suffered from this;
7th Edition was small enough that it was sensibly possible to
read the entire manual and the entire source code for the
whole caboodle, including all the commands, compilers, papers
and so on. Today, it is not possible for you even to keep up
with the changes, beyond the small subset that you personally
are interested in.]

> Second, I'd say that where a programmer has to produce a new utility
> function (it's not in the language, not in the standard library, and
> not even in a library which someone else has published) it should be
> identified by a name rather than by a string of punctuation
> characters, and that name should be used in a syntax in which the
> precedence is apparent and unquestionable; the name will at least
> give a reader some idea as to what the function does.

Name: yes, of course. Precedence: that has, see above,
to be specified for dyadic operators. But it is still the case
that mathematicians will prefer, and find more readable, symbols
such as "+" where addition [and other standard operations] are
applied to new types.

> In your example, a >= the reader something about the purpose, would happen with obvious
> precedence and is meaningfully enunciable and is therefore a better
> approach, IMO.

You've perhaps forgotten, but ">=<" was /your/ example,
as was the idea that it was to shuffle bits. I used "+<", as
"<" couldn't be used, to give at least some impression of a
chained "<". It would have been much less clear as a function.

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

Re: Chained comparisons A < B < C

<smckg0$tdm$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1211&group=comp.lang.misc#1211

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 9 Nov 2021 01:56:16 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ce83966d824a2449bbe6eca6ad3719b1";
logging-data="30134"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/FgjBMWMByDEjGT9x5a8qtP+nNP1p3Igg="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Cancel-Lock: sha1:OrpFMP7Tl7relnV1nuu/KESEwK4=
In-Reply-To: <smcdrl$s1e$1@gioia.aioe.org>

by: Bart - Tue, 9 Nov 2021 01:56 UTC

On 09/11/2021 00:03, Andy Walker wrote:
> On 07/11/2021 15:49, James Harris wrote:
> [I wrote:]
>>>      Sorry, but why do you think that creating a new operator
>>> is [other things being equal] a worse practice than creating a
>>> new function with the same parameters, code, specification, etc?
>>> What demons are you fighting?
>> Fighting demons may describe your approach to problem solving if you
>> are doing so by defining brand new operator symbols but I suggest
>> that there are specific problems with doing so:
>
>     I wasn't talking about problem solving but about a weird
> frame of mind in which you are happy for people to write
>
>    proc wertyuiop = (int a, b) bool: a > b;
>
> [adjust to whatever your preferred syntax for procedure declarations
> is], but
>
>    op wertyuiop = (int a, b) bool: a > b;
>
> is a no-no?

It is for me. My current compiler design can't handle that.

In the syntax, consecutive identifiers don't normally occur. When they
do, as in:

A B ...

it is assumed that A is user-type, and B is a new variable. With
user-defined named operators, then:

A B ...

could still mean A is type, or A is a variable and B is an postfix/infix
operator, or A is a unary operator and B is a variable, or another unary
operator.

It's not parsable. It would need an extra pass, perhaps two (across all
modules for whole-program compilation). It's not worth it.

User-defined named operators /could/ be added, but would need a special
prelude and special rules:

* Names that are to be operators need to be listed in the main module
(or the main header I now use to describe all the modules). That info
needs to include their precedence, and whether unary, binary, prefix
etc; everything needed to be construct a proper AST.

* Those names become reserved words so have program-wide scope and
cannot be redefined

* There can only be one instance of each name across the program.

* The operators would still need defining like functions are, with
operand types, bodies and return types

* Possibly, the op-defining functions are regular functions, with
directives to link the new operator names to the function.

Re: Chained comparisons A < B < C

<smg116$iir$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1243&group=comp.lang.misc#1243

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: james.harris.1@gmail.com (James Harris)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 10 Nov 2021 08:48:38 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="b05cfa0f087b5bca78f4a91c981d63c7";
logging-data="19035"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18kQXvLMDmoQMtGNUcIOtpD1UWN9w1EfzU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:2hSznk41Oo37hUyVv2XErjmI/R4=
In-Reply-To: <smcdrl$s1e$1@gioia.aioe.org>
Content-Language: en-GB

by: James Harris - Wed, 10 Nov 2021 08:48 UTC

On 09/11/2021 00:03, Andy Walker wrote:
> On 07/11/2021 15:49, James Harris wrote:

....

>> 1. While well-known operators are enunciable (e.g. := can be read as
>> "becomes" and >= can be read as "is greater than or equal to") in a
>> way that reflects their meaning that's not true of new ones. For
>> example, how would you read any of these:
>>    @:
>>    #~
>>    %!?
>
>     In Algol?

No, the examples were of the principle rather than for a specific language.

....

>> but didn't you recently show code in which
>> Algol allows programmers to define the precedence of new operators?
>
> It not merely allows, it requires that for /new/ dyadic
> operators. How else could a compiler know what precedence to
> use?

User-assignable precedence for user-defined operators is no problem for
the compiler! I was saying that it is a problem for humans reading the
code because there's nothing in the context in which they appear to
indicate how they are supposed to be combined with adjacent operators.

Yes, a human could find where the unfamiliar operator had been defined
and given a priority and then work out how that relates to adjacent
operators but I suggest that it would be better if the way the operator
relates to its surroundings were to be present in the code where the
operator was used.

>
>> If so, that also helps to make expressions unreadable for the reasons
>> I set out before, i.e. that in an expression such as
>> a or b #? c + d
>> there is no clue as to how #? it will be parsed relative to the
>> operators on either side of it.
>
> Again, you're seeing gremlins where none exist. IRL,
> bad programmers write unreadable and incompetent code in any
> language

What's bad about the expression, above? It involves only three
operators! Yet someone reading it cannot tell what order they are
applied in. I'm sorry but you cannot blame the programmer. The facility
itself is at fault.

> [even Basic], and good programmers write readable
> and competent code in any language [even (deleted)]. But in
> return, the reader has to make the effort to become familiar
> with the language.

....

>> In your example, a >=> the reader something about the purpose, would happen with obvious
>> precedence and is meaningfully enunciable and is therefore a better
>> approach, IMO.
>
> You've perhaps forgotten, but ">=<" was /your/ example,

You gave the example. You contrasted it with "myweirdfunc".

> as was the idea that it was to shuffle bits. I used "+<", as
> "<" couldn't be used, to give at least some impression of a
> chained "<".

OK.

> It would have been much less clear as a function.
>

That is a legitimate argument and deserves a fuller discussion but, for
this thread, while I see the point of it I don't believe it justifies
the problems which defining new operators with their own precedences
causes. There are better potential solutions such as building behaviour
into a language or providing a way to use user-defined named operators
in a way that their precedence and their nature are fixed or apparent in
the syntax - but that's another topic.

--
James Harris

Re: Chained comparisons A < B < C

<smgg6a$5h7$1@gioia.aioe.org>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1252&group=comp.lang.misc#1252

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!aioe.org!hzH9W6jJqCaoslGwVpYj5g.user.46.165.242.75.POSTED!not-for-mail
From: anw@cuboid.co.uk (Andy Walker)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="5671"; posting-host="hzH9W6jJqCaoslGwVpYj5g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB

by: Andy Walker - Wed, 10 Nov 2021 13:07 UTC

On 10/11/2021 08:48, James Harris wrote:
> User-assignable precedence for user-defined operators is no problem
> for the compiler! I was saying that it is a problem for humans
> reading the code because there's nothing in the context in which they
> appear to indicate how they are supposed to be combined with adjacent
> operators.

IRL, it quite simply is not and never has been a problem
for humans. Yes, of course you can write puzzles; but people with
serious intent to write useful code don't do that. There are four
uses for new operators:

-- monadic operators ["if isprime i then ..."]. Not a problem.
-- extensions of standard operators to new types. Not a problem.
-- operators that relate to the problem at hand [eg, dot and cross
multiplication of vectors], where you can reasonably expect the
precedence to follow the maths/physics/genetics/whatever.
-- The rest. I've never seen any of these.

> Yes, a human could find where the unfamiliar operator had been
> defined and given a priority and then work out how that relates to
> adjacent operators but I suggest that it would be better if the way
> the operator relates to its surroundings were to be present in the
> code where the operator was used.

If there's a difficulty [I've never seen one], you could
always add a comment. Otherwise, what do you have in mind? Some
new syntax for every time you use an operator? ???

>>> If so, that also helps to make expressions unreadable for the reasons
>>> I set out before, i.e. that in an expression such as
>>> a or b #? c + d
>>> there is no clue as to how #? it will be parsed relative to the
>>> operators on either side of it.
>> Again, you're seeing gremlins where none exist. IRL,
>> bad programmers write unreadable and incompetent code in any
>> language
> What's bad about the expression, above? It involves only three
> operators! Yet someone reading it cannot tell what order they are
> applied in. I'm sorry but you cannot blame the programmer. The
> facility itself is at fault.

The reason you "cannot tell" is that you have no idea what
"#?" is supposed to mean. If you were familiar with the problem
in which "#?" seemed to the programmer to be a Good Idea, then you
would presumably know whether it was "like" [eg] an addition, or a
logical operator, or some sort of assignment, or whatever. If not,
then you're going to have to work a little harder, eg by referring
back to where "#?" was defined; whether the fault is then with the
programmer writing obscure code or with the reader being unfamiliar
with the problem is another matter, but it's unreasonable to blame
the language. The "facility itself" is extremely useful -- once
you've used it, you'll wonder how you managed without.

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

Re: Chained comparisons A < B < C

<smgk6e$pao$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1253&group=comp.lang.misc#1253

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 10 Nov 2021 14:15:42 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="9fcad5482fc717d5fd6593d067a5dec3";
logging-data="25944"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18E3fvXu5blFk7u696yNfgEnBGc26mlFD8="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Cancel-Lock: sha1:HuTwhm9Q/aaPWYCoXIOpEkY2E/0=
In-Reply-To: <smgg6a$5h7$1@gioia.aioe.org>

by: Bart - Wed, 10 Nov 2021 14:15 UTC

On 10/11/2021 13:07, Andy Walker wrote:
> On 10/11/2021 08:48, James Harris wrote:
>> User-assignable precedence for user-defined operators is no problem
>> for the compiler! I was saying that it is a problem for humans
>> reading the code because there's nothing in the context in which they
>> appear to indicate how they are supposed to be combined with adjacent
>> operators.
>
>     IRL, it quite simply is not and never has been a problem
> for humans. Yes, of course you can write puzzles; but people with
> serious intent to write useful code don't do that. There are four
> uses for new operators:
>
> -- monadic operators ["if isprime i then ..."]. Not a problem.
> -- extensions of standard operators to new types. Not a problem.
> -- operators that relate to the problem at hand [eg, dot and cross
>      multiplication of vectors], where you can reasonably expect the
>      precedence to follow the maths/physics/genetics/whatever.
> -- The rest. I've never seen any of these.
>
>> Yes, a human could find where the unfamiliar operator had been
>> defined and given a priority and then work out how that relates to
>> adjacent operators but I suggest that it would be better if the way
>> the operator relates to its surroundings were to be present in the
>> code where the operator was used.
>
>     If there's a difficulty [I've never seen one], you could
> always add a comment. Otherwise, what do you have in mind? Some
> new syntax for every time you use an operator? ???

Creating a new operator with a new precedence /is/ changing the syntax.

Actually, in Algol68 you can change the syntax even with no new operators:

PRIO + = 9;
PRIO * = 5;

print((2+3*4))

The results depend on the relative priorities of + and *; I can get 14,
or 20.

(I had to define both here because I don't know what the default
priorities of + and * are. I'd have to go and dig up that info
somewhere. All I know is that * is normally higher than +.)

Or, I can get both results from the same program:

print((2+3*4));

BEGIN
PRIO + = 5;
PRIO * = 9;

print((2+3*4))
END;

PRIO + = 9;
PRIO * = 5;

In this case, I've put one set of PRIOs at the end, so that the
behaviour of 2+3*4 is even more surprising, since you don't know about
that override until the end of a normally much longer program.

To me this is all undesirable. I would favour:

* Having only a fixed set of built-in operator with fixed precedences

* Possibly, having some additional built-in symbolic operators which are
unassigned, available for user-programs to overload. Again with fixed
precedences (but likely to be just one)

Re: Chained comparisons A < B < C

<smh89a$idt$1@gioia.aioe.org>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1261&group=comp.lang.misc#1261

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!aioe.org!hzH9W6jJqCaoslGwVpYj5g.user.46.165.242.75.POSTED!not-for-mail
From: anw@cuboid.co.uk (Andy Walker)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="18877"; posting-host="hzH9W6jJqCaoslGwVpYj5g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2

by: Andy Walker - Wed, 10 Nov 2021 19:58 UTC

On 10/11/2021 14:15, Bart wrote:
[I wrote (to James):]
>> [...] Otherwise, what do you have in mind? Some
>> new syntax for every time you use an operator? ???
> Creating a new operator with a new precedence /is/ changing the syntax.

It's a point of view; but James was talking about /applied/
occurrences of the operator, not /defining/ occurrences.
> Actually, in Algol68 you can change the syntax even with no new operators:

What do you mean by "change the syntax"? Any non-trivial
change to a program is changing the syntactic structure of that
program; but neither in Algol 68 nor in most other languages is
there any way for a program to change its underlying syntax. In
Algol, the syntax of formulas is defined in RR5.4.2.1 and stays
the same no matter what games you play with priorities.

>     PRIO + = 9;
>     PRIO * = 5;
>     print((2+3*4))

Yeah, you can write puzzles. And ...? As an entry in an
"Obfuscated Algol" competition, you can sensibly do things like
that. In normal code, you can't, and most people would regard it
as Bad programming. But [in Algol] there has to be provision for
it, otherwise there would be no way to define "+" and "*" in the
first place -- they're not hard-wired in the syntax, only in the
code of the standard prelude.

[...]
> To me this is all undesirable. I would favour:
> * Having only a fixed set of built-in operator with fixed precedences

With or without allowing code to re-define operators for
other types? It would seriously impact most of my interesting
programs if I couldn't use [eg] "+", "-" and "*" for things like
graphs and games, or different sorts of number -- might as well
use C or other restricted language. Not /quite/ so bad if that's
allowed but defining new operators is disallowed, though that
would still affect perhaps half of my non-trivial programs. It
would be a major change however to allow code in the standard
prelude that was not syntactically/semantically available inside
the program [it would affect the entire structure of programs].

> * Possibly, having some additional built-in symbolic operators which
> are unassigned, available for user-programs to overload. Again with
> fixed precedences (but likely to be just one)

IOW, you want to exercise control over the symbolisms
used in my programs, as though you were an expert in whatever
field happens to be relevant to my programming task? I want
to use something for, say circle-plus, and I need to find out
whether you have graciously provided a symbol for just that
purpose, otherwise I'm SOL, and will have to resort to Algol
instead to write my program. Fine, but I [therefore] won't
be interested in your language.

The only reason you and James seem to have for not
liking new operators is that they can be abused by bad
programmers. Yes; and ...? Do we invent interesting
languages for the benefit of bad programmers or so that
we can write interesting [and useful] programs?

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

Re: Chained comparisons A < B < C

<smhegt$e89$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1262&group=comp.lang.misc#1262

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
<smh89a$idt$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 10 Nov 2021 21:45:01 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="9fcad5482fc717d5fd6593d067a5dec3";
logging-data="14601"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19dYY3qXltkvnLW1ErWml0mP/1E9UratR4="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Cancel-Lock: sha1:3u5dg7j8Gynnp7rBwRBG/v/pdg4=
In-Reply-To: <smh89a$idt$1@gioia.aioe.org>

by: Bart - Wed, 10 Nov 2021 21:45 UTC

On 10/11/2021 19:58, Andy Walker wrote:
> On 10/11/2021 14:15, Bart wrote:
> [I wrote (to James):]
>>> [...] Otherwise, what do you have in mind? Some
>>> new syntax for every time you use an operator? ???
>> Creating a new operator with a new precedence /is/ changing the syntax.
>
> It's a point of view; but James was talking about /applied/
> occurrences of the operator, not /defining/ occurrences.
>> Actually, in Algol68 you can change the syntax even with no new
>> operators:
>
> What do you mean by "change the syntax"? Any non-trivial
> change to a program is changing the syntactic structure of that
> program; but neither in Algol 68 nor in most other languages is
> there any way for a program to change its underlying syntax.

Syntax for me includes whether a + b * c is parsed as a + (b * c) or as
(a + b) * c. In other words, the structure of an expression.

But a language can be defined so that any expression is the linear:

term | binop

(a series of terms separated with binops) with the actual semantics
depending on the attributes of those operators. (Eg. table-driven
expression parsers, which is what I've used myself.)

However I don't see that as being so useful. I think hard-coded
precedences, fixed in the grammar, are better. But even my
table-specified precedences were fixed; you couldn't change the meaning
of a+b*c from a+(b*c) to (a+b)*c from one line to the next, and then
back again.

Sometimes a language can give too much freedom.

>>      PRIO + = 9;
>>      PRIO * = 5;
>>      print((2+3*4))
>
>     Yeah, you can write puzzles. And ...? As an entry in an
> "Obfuscated Algol" competition, you can sensibly do things like
> that. In normal code, you can't,

Then disallow it.

and most people would regard it
> as Bad programming. But [in Algol] there has to be provision for
> it, otherwise there would be no way to define "+" and "*" in the
> first place -- they're not hard-wired in the syntax, only in the
> code of the standard prelude.

(1) If that's how Algol is implemented, then OK, but it's not drawing a
proper line between different kinds of code: implementation, standard
libraries, third party libraries, and user libraries and code.

(2) Even if PRIO is needed to set a precedence, it could allow it just
once per distinct operator

(3) How is "+" defined in Algol 68?

> [...]
>> To me this is all undesirable. I would favour:
>> * Having only a fixed set of built-in operator with fixed precedences
>
> With or without allowing code to re-define operators for
> other types?

I've specified the operators availble for overload. The standard ones,
and few predefined spare ones. I think a few languages do the same thing.

The sensible ones may have learned that having free-for-all on operator
names is not a good idea. Being able to use Unicode identifiers is worse.

>> * Possibly, having some additional built-in symbolic operators which
>> are unassigned, available for user-programs to overload. Again with
>> fixed precedences (but likely to be just one)
>
> IOW, you want to exercise control over the symbolisms
> used in my programs, as though you were an expert in whatever
> field happens to be relevant to my programming task? I want
> to use something for, say circle-plus, and I need to find out
> whether you have graciously provided a symbol for just that
> purpose, otherwise I'm SOL, and will have to resort to Algol
> instead to write my program. Fine, but I [therefore] won't
> be interested in your language.

Doesn't Algol68 limit the available symbols anyway? Eg. you couldn't use
"<". I couldn't use "+++" when I tried that.

I assume there are rules so that you can resolve "+++" and "+ + +",
especially of the language likes to ignore white space.

Re: Chained comparisons A < B < C

<smjruf$19qn$1@gioia.aioe.org>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1269&group=comp.lang.misc#1269

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!aioe.org!hzH9W6jJqCaoslGwVpYj5g.user.46.165.242.75.POSTED!not-for-mail
From: anw@cuboid.co.uk (Andy Walker)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
<smh89a$idt$1@gioia.aioe.org> <smhegt$e89$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="42839"; posting-host="hzH9W6jJqCaoslGwVpYj5g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
X-Mozilla-News-Host: news://nntp.aioe.org
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2

by: Andy Walker - Thu, 11 Nov 2021 19:46 UTC

On 10/11/2021 21:45, Bart wrote:
>>> Actually, in Algol68 you can change the syntax even with no new operators:
>> What do you mean by "change the syntax"? Any non-trivial
>> change to a program is changing the syntactic structure of that
>> program; but neither in Algol 68 nor in most other languages is
>> there any way for a program to change its underlying syntax.
> Syntax for me includes whether a + b * c is parsed as a + (b * c) or
> as (a + b) * c. In other words, the structure of an expression.

If your language has a syntax that specifies that, then fine;
but Algol doesn't. It has a two-level grammar, so that the syntax
includes lots of other things, such as whether an identifier has
been declared, whether types match, and so on. I don't propose to
write an essay on 2LGs, it's all in the RR, and I've previously
referred you to the actual syntax of formulas in RR5.4.2.1. It
includes what other languages would call semantics.

> [...] I think hard-coded
> precedences, fixed in the grammar, are better.

Yes, I understand that to be your opinion. But the only
rationale you have produced for that is that rogue programmers
can abuse declared priorities. Oh, and that your own compiler
can't handle it. Are we inventing languages for rogue programmers
or for productivity?

>> [...] As an entry in an
>> "Obfuscated Algol" competition, you can sensibly do things like
>> that. In normal code, you can't,
> Then disallow it.

It's 46 years too late to change the RR. Esp when there
is no reason to. IRL it simply is not a problem, and it would
complicate the syntax.

>> [...] But [in Algol] there has to be provision for
>> it, otherwise there would be no way to define "+" and "*" in the
>> first place -- they're not hard-wired in the syntax, only in the
>> code of the standard prelude.
> (1) If that's how Algol is implemented, then OK, but it's not drawing
> a proper line between different kinds of code: implementation,
> standard libraries, third party libraries, and user libraries and
> code.

That's not how Algol is /implemented/, it's how it is
/defined/ [and it's again 46 years too late to change that].
But it does draw those lines, indeed rather more carefully than
most if not all other language definitions. See RR10.1.

> (2) Even if PRIO is needed to set a precedence, it could allow it
> just once per distinct operator

It could. But it would cut across the whole concept of
block structure; eg, you couldn't embed a program inside another
one and expect the result to be legal. [It would actually be a
fairly simple change to RR4.2.1b. But there really, really, is
absolutely no need, and it would prevent a handful of interesting
applications.]

> (3) How is "+" defined in Algol 68?

RR10.2.3.0a for the priority and an infinity of rules
typified by RR10.2.3.3i which defines it for integers, plus
similar versions for monadic "+", other lengths and other
parameter types. If you're really interested, you need to see
also RR10.1.3, which gives the same freedom as C's "as-if" rule,
and RR2.1.3.1e which sets out the assumed properties of numbers.

> Doesn't Algol68 limit the available symbols anyway? Eg. you couldn't
> use "<". I couldn't use "+++" when I tried that.

I could have used "<", but that would have over-written
the standard meaning of "<". If you mean that you couldn't
declare an operator "+++", then [as I have already explained in
this thread several times] A68 operators are not free-for-all;
see RR9.4.2.1F for dyadic operators, RR9.4.2.1K for monadic.
[Trying things is Good, but you will ultimately save your own,
and more importantly my, time if you read the Revised Report.]

> I assume there are rules so that you can resolve "+++" and "+ + +",
> especially of the language likes to ignore white space.

Yes; "a +++ b" means [unambiguously, and however you
try to redefine operators] "a + ( + ( + b ) )", that is, a
dyadic operator and two monadic; "a + + + b" means the same,
but in any case you aren't allowed white space [or comments!]
internally to an operator symbol.

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

Re: Chained comparisons A < B < C

<smk08a$cvi$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1271&group=comp.lang.misc#1271

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
<smh89a$idt$1@gioia.aioe.org> <smhegt$e89$1@dont-email.me>
<smjruf$19qn$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 11 Nov 2021 20:59:54 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="474a6bc201dcba95ce9c7f0dc58ab1d7";
logging-data="13298"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+3AAS+5VTpB7pw2kUVO/j9peLojv2j58E="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Cancel-Lock: sha1:tW30Tr86im+bNsP8wll4QYOfXAY=
In-Reply-To: <smjruf$19qn$1@gioia.aioe.org>

by: Bart - Thu, 11 Nov 2021 20:59 UTC

On 11/11/2021 19:46, Andy Walker wrote:
> On 10/11/2021 21:45, Bart wrote:
>>>> Actually, in Algol68 you can change the syntax even with no new
>>>> operators:
>>>      What do you mean by "change the syntax"? Any non-trivial
>>> change to a program is changing the syntactic structure of that
>>> program; but neither in Algol 68 nor in most other languages is
>>> there any way for a program to change its underlying syntax.
>> Syntax for me includes whether a + b * c is parsed as a + (b * c) or
>> as (a + b) * c. In other words, the structure of an expression.
>
>     If your language has a syntax that specifies that, then fine;
> but Algol doesn't. It has a two-level grammar, so that the syntax
> includes lots of other things, such as whether an identifier has
> been declared, whether types match, and so on. I don't propose to
> write an essay on 2LGs, it's all in the RR, and I've previously
> referred you to the actual syntax of formulas in RR5.4.2.1. It
> includes what other languages would call semantics.
>
>> [...] I think hard-coded
>> precedences, fixed in the grammar, are better.
>
>     Yes, I understand that to be your opinion. But the only
> rationale you have produced for that is that rogue programmers
> can abuse declared priorities. Oh, and that your own compiler
> can't handle it.

You misunderstood. My compilers for decades have had table-driven
expression parsers, but with non-alterable priorities. I'm using
grammar-driven parsers now as they are clearer, and make it easier to
add specialist handling to some operators (eg. chained comparisons).

> Are we inventing languages for rogue programmers
> or for productivity?

Both mine are for own productivity. That means 90% working on on my code
instead of 90% battling the compiler.

I don't suffer from the lack of user-defined ops in the stuff I do.

But I /would/ suffer from the lack of many of my features, such as
'tabledata', using a foreign language like yours.

>>> [...] As an entry in an
>>> "Obfuscated Algol" competition, you can sensibly do things like
>>> that. In normal code, you can't,
>> Then disallow it.
>
> It's 46 years too late to change the RR.

Why does it have to be fixed? Other languages evolve. Among the changes
I would make to Algol68:

* Fix the semicolon problem, or making it quietly tolerant

* Get rid of that spaces-in-identifiers stuff, so that you don't need
keyword stropping, and people can write code in a civilised manner.

I don't care about the operator stuff, as I never use it.

>> (3) How is "+" defined in Algol 68?
>
> RR10.2.3.0a for the priority and an infinity of rules
> typified by RR10.2.3.3i which defines it for integers, plus
> similar versions for monadic "+", other lengths and other
> parameter types. If you're really interested, you need to see
> also RR10.1.3, which gives the same freedom as C's "as-if" rule,
> and RR2.1.3.1e which sets out the assumed properties of numbers.

OK, my question should have been, how do you /implement/ "+" when "+"
meaning 'add' doesn't yet exist. There must either be some core BUILT-IN
features to make it practical, or "+" is secretly built-in already.

Doesn't Algol68 limit the available symbols anyway? Eg. you couldn't
>> use "<". I couldn't use "+++" when I tried that.
>
> I could have used "<", but that would have over-written
> the standard meaning of "<". If you mean that you couldn't
> declare an operator "+++", then [as I have already explained in
> this thread several times] A68 operators are not free-for-all;
> see RR9.4.2.1F for dyadic operators, RR9.4.2.1K for monadic.
> [Trying things is Good, but you will ultimately save your own,
> and more importantly my, time if you read the Revised Report.]

So, it looks like the most apt operator you want to use probably
wouldn't be allowed. So the language is telling which you can use, or
which are legal.

Re: Chained comparisons A < B < C

<smk1fv$1s6k$1@gioia.aioe.org>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1272&group=comp.lang.misc#1272

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!aioe.org!hzH9W6jJqCaoslGwVpYj5g.user.46.165.242.75.POSTED!not-for-mail
From: anw@cuboid.co.uk (Andy Walker)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slq4ri$hg8$1@dont-email.me>
<sm1p48$sip$1@gioia.aioe.org> <sm22vs$k1l$1@dont-email.me>
<sm70n9$666$1@gioia.aioe.org> <sm8ese$vvp$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="61652"; posting-host="hzH9W6jJqCaoslGwVpYj5g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2

by: Andy Walker - Thu, 11 Nov 2021 21:21 UTC

On 07/11/2021 11:55, Bart wrote:
>>> I'm talking about introducing arrays to what appeared to be an
>>> implementation of chained operators. Are they central to being able
>>> to implement an arbitrary list of such comparisons, or are they there
>>> for a different reason?
>> Algol doesn't have "lists" as opposed to arrays, so if we
>> want to implement [eg] "+< somearray" to mean a chained comparison
>> between the elements of the array [similar, apparently to your
>> "mapsv (('<'), ...)", then of course "somearray" has to be an
>> array. I still don't see why it's so strange to involve/introduce
>> arrays to implement an indefinitely-long chain.
> In the user code the elements do not form an array. The comparisons
> are done with dedicated code for each, not using a loop. Inside the
> compiler, it could make use of arrays, but the input source and
> output code probably won't.

I still don't have the slightest idea what you are complaining
about. FTAOD /yet again/, I have personally never felt the need to
use "chained comparisons" , even less to write programs that define
them as operators, but it seemed like a modestly interesting task,
so I spent a few minutes demonstrating that it was possible in
Algol. The actual "<" operator was already [unsurprisingly] in
use, so I had to use a new symbol, and chose, rather arbitrarily,
"+<". It was then easy to implement "a +< b". For good measure,
I chucked in a monadic version [optional extra] such that
"+< c" returned true iff the elements of "c" were sorted; that
used [unsurprisingly] an array [which you seem to be complaining
about] and a loop [which you seem to be complaining about /not/
being used, even though it manifestly is]. If you can create a
comprehensible question, I can try to answer it, but ATM I have
no idea what you're trying to say about arrays.

> The consequences of your A68 solution is that it takes 4 times as
> long to do 'a <+ b <+ c < d', as it does to do 'a < d' [10 secs vs 2.5 secs for 10 million iterations].

It's an order of magnitude faster on my PC, but the ratio is
[unsurprisingly] the same. That's for the obvious reason that the
"a < b AND b < c AND c < d" version does six loads and five built-in
operations whereas "a +< b +< c < d" saves two loads but has to do
the same operations /plus/ two function calls, and a lot of parameter
establishment [as the intermediate type is a structure] and passing.

> When I make the same comparison in my languages, I get the same
> timing, although that's because these simple expressions end up as
> the same code. [0.75 secs for 1 billion iterations static, 0.85 secs
> for 100M, dynamic]

Or because your version is compiled and optimised, whereas
mine is interpreted and unoptimised. ICBA to run it through the
unit optimiser, after which the main time [in A68G] would presumably
be that spent running a trivial loop 10^7 [or 10^9] times.

> So in this case, emulating such a construct in user code results in
> an inferior version: funnier syntax, and not as efficient.

It's not surprising that an unoptimised interpretation is
"less efficient" than compiled and optimised. Whether it's
"inferior" is a matter of taste. Again, it's not code that I
would ever write in normal circumstances.

> But a side
> effect is that you get +< or <+ (how do you remember which it is) to
> act on arrays of ints.

Not a "side effect"; I wrote an extra operator. As "<+"
[which you managed somehow to perpetrate above] is not a legal A68
operator, it's easy to remember which one I used.

> (A reminder that this solution only works for "<",

Yes, as I commented in the original code; it would be a
waste of everyone's time [esp mine] to write out five copies of
the same code but replacing "<" by "<=", "=", "/=", ">" and ">="
just for completeness ...

> only for INTs,

... and a further waste of time writing out further copies
for every possible combination of parameter types. If this had
been a real problem and not a mere proof of concept, I would have
written a shell script to generate the ~1440 [~5000 with your
preferred layout] lines of very repetitive code needed. Yet
again, it really would have been silly.

> and
> may not allow mixed comparisions like a <= b < c.)

But yes, those would all then be legal.

[...]
> The trend is now to declare only one thing per line, even variables.

Yeah, I've had spells of doing that. But that was before
we had "screens", and having acres of white space on the lineprinter
listings was useful for writing edits/corrections in the days before
we had usable editors or even files. Or simply guillotining off the
printing and stapling together pads of blank paper. Not quite as
bad as the author who wrote as an exercise "Write a program to print
the squares of the integers from 1 to 1000, each on a new page" --
I bet he was popular with his computing centre.

> (A very strange feature. print(~) just shows SKIP. Assigning it to an
> int stores 1. Assigning to a REAL stores some random value. Assigning
> to a string stores "".
> At the least I would have expected 0 and 0.0 to be stored for
> numbers, ie. 'empty' or 'zero'.)

It's a "skip" token. If you want 0 or 0.0 then write that,
don't tell the compiler that you don't care and then be surprised by
the result. "What drink do you want?" "Don't care." ... "Why have
you brought me iced tea, I was expecting white wine."

[...]
> (My editor also displays 60 lines, not 25.)

Lucky you. Most of my screens are not tall enough for that
[and the exception is busy displaying music, which needs lots of
space, esp for orchestral parts]. T'bird occupies more than half
the available height with headers, other windows and margins, to
even 25 lines is pushing it; my own editor will run to about 40
lines before the font size gets too small [for me] to read, but
if I'm using a split screen to compare two chunks of code it's
difficult for either to be much more than 25.

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

Re: Chained comparisons A < B < C

<smkead$7u1$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1275&group=comp.lang.misc#1275

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slq4ri$hg8$1@dont-email.me>
<sm1p48$sip$1@gioia.aioe.org> <sm22vs$k1l$1@dont-email.me>
<sm70n9$666$1@gioia.aioe.org> <sm8ese$vvp$1@dont-email.me>
<smk1fv$1s6k$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 12 Nov 2021 00:59:57 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="2e1d49733d326e7eab16cde29de51166";
logging-data="8129"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/fj9Gs/EjpXVLNX7zzrtIitrd3Z/U046Y="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Cancel-Lock: sha1:nQSLa+nJv92KNShNHPr/8x4Mfik=
In-Reply-To: <smk1fv$1s6k$1@gioia.aioe.org>

by: Bart - Fri, 12 Nov 2021 00:59 UTC

On 11/11/2021 21:21, Andy Walker wrote:
> On 07/11/2021 11:55, Bart wrote:
>>>> I'm talking about introducing arrays to what appeared to be an
>>>> implementation of chained operators. Are they central to being able
>>>> to implement an arbitrary list of such comparisons, or are they there
>>>> for a different reason?
>>> Algol doesn't have "lists" as opposed to arrays, so if we
>>> want to implement [eg] "+< somearray" to mean a chained comparison
>>> between the elements of the array [similar, apparently to your
>>> "mapsv (('<'), ...)", then of course "somearray" has to be an
>>> array. I still don't see why it's so strange to involve/introduce
>>> arrays to implement an indefinitely-long chain.
>> In the user code the elements do not form an array. The comparisons
>> are done with dedicated code for each, not using a loop. Inside the
>> compiler, it could make use of arrays, but the input source and
>> output code probably won't.

I was asking how arrays came in it. You said of course there has to be
an array. But not really; you don't need arrays for:

a + b + c

so why do you need them for:

a < b < c

The answer was that your A68 solution needs to use arrays to make it
work even for a handful of scalar values. And a side-effect of that was
to be able to do < (10,20,30) (even if needing a cast).

>> When I make the same comparison in my languages, I get the same
>> timing, although that's because these simple expressions end up as
>> the same code. [0.75 secs for 1 billion iterations static, 0.85 secs
>> for 100M, dynamic]
>
> Or because your version is compiled and optimised, whereas
> mine is interpreted and unoptimised.

That 0.85 secs for 100 million is for my interpreted bytecode.

My point really is that implementing stuff in /user-code/ is going to
have performance problems when that user-code is interpreted.

> It's not surprising that an unoptimised interpretation is
> "less efficient" than compiled and optimised.

That isn't always an option, not when using dynamic typing as geting it
optimised gets very difficult (they've been trying it for years with
Python).

> ... and a further waste of time writing out further copies
> for every possible combination of parameter types. If this had
> been a real problem and not a mere proof of concept, I would have
> written a shell script to generate the ~1440 [~5000 with your
> preferred layout] lines of very repetitive code needed. Yet
> again, it really would have been silly.

This is yet another problem. Your script to generate that lot may be
short, but it would still be 1400 lines of dense code to end up doing a
poorer, slower emulation of something my language can do in 100
non-dense lines because it is natively supported.

You may also need to process all that extra code when a program doesn't
use the feature.

These are all disadvantages of using language-building features in
user-code to implement functionality, as opposed to having direct
language support.

Everyone here seems to like that former approach.

>> (A very strange feature. print(~) just shows SKIP. Assigning it to an
>> int stores 1. Assigning to a REAL stores some random value. Assigning
>> to a string stores "".
>> At the least I would have expected 0 and 0.0 to be stored for
>> numbers, ie. 'empty' or 'zero'.)
>
> It's a "skip" token. If you want 0 or 0.0 then write that,
> don't tell the compiler that you don't care and then be surprised by
> the result.

So, a very strange feature. Effectively it returns some random value?

Sometimes a value is unimportant, but you still want a program to give
consistent, repeatable results.

> "What drink do you want?" "Don't care." ... "Why have
> you brought me iced tea, I was expecting white wine."

An empty glass every time?

> [...]
>> (My editor also displays 60 lines, not 25.)
>
> Lucky you. Most of my screens are not tall enough for that

Either you are still using a display from the 1970s, or you need to use
a giant font (or maybe you're posting from a smartphone).

At times I've also turned my display 90 degrees (portrait mode) to
better view scanned documents and such, a whole page at a time.

Re: Chained comparisons A < B < C

<smmhs3$1q0n$1@gioia.aioe.org>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1290&group=comp.lang.misc#1290

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!aioe.org!hzH9W6jJqCaoslGwVpYj5g.user.46.165.242.75.POSTED!not-for-mail
From: anw@cuboid.co.uk (Andy Walker)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
<smh89a$idt$1@gioia.aioe.org> <smhegt$e89$1@dont-email.me>
<smjruf$19qn$1@gioia.aioe.org> <smk08a$cvi$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="59415"; posting-host="hzH9W6jJqCaoslGwVpYj5g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2

by: Andy Walker - Fri, 12 Nov 2021 20:12 UTC

On 11/11/2021 20:59, Bart wrote:
>>> [...] I think hard-coded
>>> precedences, fixed in the grammar, are better.
>> Yes, I understand that to be your opinion. But the only
>> rationale you have produced for that is that rogue programmers
>> can abuse declared priorities. Oh, and that your own compiler
>> can't handle it.
> You misunderstood. My compilers for decades have had table-driven
> expression parsers, but with non-alterable priorities. I'm using
> grammar-driven parsers now as they are clearer, and make it easier to
> add specialist handling to some operators (eg. chained comparisons).

/You/ described Algol 68 operators are being "unparsable".
In general, that's manifestly untrue as A68 compilers have been
around for over half a century; what else am I to understand from
your comment than that you were referring to /your/ compiler rather
than Joe Bloggs's compiler? If you're saying that you now /can/
compile the devious examples that you drew attention to earlier,
then good; well done.

>> Are we inventing languages for rogue programmers
>> or for productivity?
> Both mine are for own productivity. That means 90% working on on my
> code instead of 90% battling the compiler.

Personally, I find it easier and more productive to work
/with/ the compiler rather than against it, and then spend 100%
on my own code. But then, I have, of course, managed to read the
RR and even to read MvdV's description of A68G.

> I don't suffer from the lack of user-defined ops in the stuff I do.

Nor do I.

> But I /would/ suffer from the lack of many of my features, such as
> 'tabledata', using a foreign language like yours.

Well, yes, if you like piggling with compilers and your
own language, then of course it will have your features rather
than mine. That's no use to me or anyone else here, as your
compiler is both changing under our feet and undocumented, so
it's [as far as we can tell] full of things we don't know about
and so can't use, even if we snaffle your binary.

>>> Then disallow it.
>> It's 46 years too late to change the RR.
> Why does it have to be fixed? Other languages evolve.

Yes, and either it's a total incompatible mess or else
[more sensibly] the versions are called [eg] "K&R C", "C99", ...
"C2x". The RR is in hard copy. We don't have magic typesetters
to re-write history. If you want an Algol 23, contact IFIP and
offer your services. Good luck in finding enough people with
enough interest. It's more important to me to be able to run
the A68 programs I've accumulated over ~50 years than to write
a somewhat similar language with cosmetic changes and no real
advantages. A68G will see me out; Marcus has added some
interesting things [partial parametrisation and Torrix, amongst
others, but sadly not yet modals] without losing backwards
compatibility.

> OK, my question should have been, how do you /implement/ "+" when "+"
> meaning 'add' doesn't yet exist. There must either be some core
> BUILT-IN features to make it practical, or "+" is secretly built-in
> already.

The same way as every other language, I expect. The usual
way is to build an AST and walk it generating code [or some other
representation]; if you hit a "+" node at the top level, you emit
suitable machine [or whatever] code, using the "as if" rule. Not
interestingly different from how you implement "if ... then". Or
you could look at the A68G sources to see how Marcus does it.
[Other A68 compilers are available.]

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

Re: Chained comparisons A < B < C

<smmj9m$e4e$1@gioia.aioe.org>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1292&group=comp.lang.misc#1292

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!aioe.org!hzH9W6jJqCaoslGwVpYj5g.user.46.165.242.75.POSTED!not-for-mail
From: anw@cuboid.co.uk (Andy Walker)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slq4ri$hg8$1@dont-email.me>
<sm1p48$sip$1@gioia.aioe.org> <sm22vs$k1l$1@dont-email.me>
<sm70n9$666$1@gioia.aioe.org> <sm8ese$vvp$1@dont-email.me>
<smk1fv$1s6k$1@gioia.aioe.org> <smkead$7u1$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="14478"; posting-host="hzH9W6jJqCaoslGwVpYj5g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB

by: Andy Walker - Fri, 12 Nov 2021 20:37 UTC

On 12/11/2021 00:59, Bart wrote:
> I was asking how arrays came in it. You said of course there has to
> be an array. But not really; you don't need arrays for:
> a + b + c
> so why do you need them for:
> a < b < c

??? I don't and didn't. There is no array in [from my OP]

OP +< = (INT i,j) IB: ( i < j | (j, TRUE) | (~, FALSE) )

[which was the operator used in "a +< b < c"].

> The answer was that your A68 solution needs to use arrays to make it
> work even for a handful of scalar values.

No, there was an array [unsurprisingly] in the definition
of a /monadic/ "+<" designed to check whether the elements of the
array passed as its parameter are in order.

> And a side-effect of that
> was to be able to do < (10,20,30) (even if needing a cast).

Yes, that was the whole purpose [not a side effect] of
choosing to define the monadic operator. It would have more point
if we had

[1000] INT a;
FOR i TO 1000 DO a[i] := ... whatever OD;
IF +< a THEN ...

rather than

IF a[1] < a[2] AND a[2] < a[3] AND ... AND # many lines later #
a[999] < a[1000] THEN ...

> This is yet another problem. Your script to generate that lot may be
> short, but it would still be 1400 lines of dense code to end up doing
> a poorer, slower emulation of something my language can do in 100
> non-dense lines because it is natively supported.
> You may also need to process all that extra code when a program
> doesn't use the feature.

So I wrote 15 lines to demonstrate a point of principle in
a completely unimportant application [I have much more important
uses of user-defined operators in my real code]; and you wrote
100 lines to implement that unimportant application. Whatever.
None of my [real] programs will ever use that application, so
the 1400 lines will never get written and even less processed.

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

Re: Chained comparisons A < B < C

<smmlv6$bd1$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1294&group=comp.lang.misc#1294

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slq4ri$hg8$1@dont-email.me>
<sm1p48$sip$1@gioia.aioe.org> <sm22vs$k1l$1@dont-email.me>
<sm70n9$666$1@gioia.aioe.org> <sm8ese$vvp$1@dont-email.me>
<smk1fv$1s6k$1@gioia.aioe.org> <smkead$7u1$1@dont-email.me>
<smmj9m$e4e$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 12 Nov 2021 21:22:46 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="2e1d49733d326e7eab16cde29de51166";
logging-data="11681"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19CIcnyz77oaRKCxd/3lmz65kYO04ZiKY0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Cancel-Lock: sha1:YfxiCieG9B5OVk8oFAAYfnJ02Bg=
In-Reply-To: <smmj9m$e4e$1@gioia.aioe.org>

by: Bart - Fri, 12 Nov 2021 21:22 UTC

On 12/11/2021 20:37, Andy Walker wrote:
> On 12/11/2021 00:59, Bart wrote:
>> I was asking how arrays came in it. You said of course there has to
>> be an array. But not really; you don't need arrays for:
>> a + b + c
>> so why do you need them for:
>> a 
> ??? I don't and didn't. There is no array in [from my OP]
>
> OP +< = (INT i,j) IB: ( i < j | (j, TRUE) | (~, FALSE) )
>
> [which was the operator used in "a +
>> The answer was that your A68 solution needs to use arrays to make it
>> work even for a handful of scalar values.
>
> No, there was an array [unsurprisingly] in the definition
> of a /monadic/ "+<" designed to check whether the elements of the
> array passed as its parameter are in order.

Yes, that's the one I mean. I managed to delete that now and the rest
still worked. I tried that before but it gave problems (but I've since
added support in my editor for A68G comments, making it easier to
comment out a block).

So ... well I won't say anything more about that array [still not sure
why it's there!]

>> This is yet another problem. Your script to generate that lot may be
>> short, but it would still be 1400 lines of dense code to end up doing
>> a poorer, slower emulation of something my language can do in 100
>> non-dense lines because it is natively supported.
>> You may also need to process all that extra code when a program
>> doesn't use the feature.
>
> So I wrote 15 lines to demonstrate a point of principle in
> a completely unimportant application [I have much more important
> uses of user-defined operators in my real code]; and you wrote
> 100 lines to implement that unimportant application. Whatever.
> None of my [real] programs will ever use that application, so
> the 1400 lines will never get written and even less processed.

I'm not suggesting you should have done all that for a demo.

I /am/ suggesting that would be a poor way of adding such a feature to a
language, by retro-fitting it via user-code. My 100 lines handle all
type combinations for which the relevant operators are already defined
in non-chained form.

[A note to DB and DAK if they are reading this: I'm not going to be
reading their posts. Sorry about the two unread ones. If they want the
last word, they now have it.]

Re: Chained comparisons A < B < C

<smmno3$n4o$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1295&group=comp.lang.misc#1295

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
<smh89a$idt$1@gioia.aioe.org> <smhegt$e89$1@dont-email.me>
<smjruf$19qn$1@gioia.aioe.org> <smk08a$cvi$1@dont-email.me>
<smmhs3$1q0n$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 12 Nov 2021 21:53:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="2e1d49733d326e7eab16cde29de51166";
logging-data="23704"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18LII4eb9fXKTVGDSEt/mnvh26FOxP+LEw="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Cancel-Lock: sha1:cKg3gLFx5sRELFL3gFUVPQmTG3o=
In-Reply-To: <smmhs3$1q0n$1@gioia.aioe.org>

by: Bart - Fri, 12 Nov 2021 21:53 UTC

On 12/11/2021 20:12, Andy Walker wrote:
> On 11/11/2021 20:59, Bart wrote:

>> But I /would/ suffer from the lack of many of my features, such as
>> 'tabledata', using a foreign language like yours.
>
> Well, yes, if you like piggling with compilers and your
> own language,

I'm stuck with it now; I'm too spoilt to use anyone else's. But then,
it's actually pretty good, which I didn't appreciate until I /tried/ to
use others, because I did get fed up with maintaining it.

> then of course it will have your features rather
> than mine. That's no use to me or anyone else here, as your
> compiler is both changing under our feet and undocumented, so
> it's [as far as we can tell] full of things we don't know about
> and so can't use, even if we snaffle your binary.

There are examples of 'tabledata' used here:

https://github.com/sal55/langs/blob/master/Examples/ax_tables.m

Mainly, it defines parallel sets of enums, and corresponding data
arrays. Or sometimes just parallel arrays.

Trying to do the same in C requires using ugly 'x-macros'.

Before I had this feature, I had to use tables in text files and scripts
to generate the arrays as code. Having it built-in is much better. And
it's easy to implement!

(The "$" you see returns the last enum name as a string literal. This
file defines stuff for my x64 assembler.)

>>>> Then disallow it.
>>> It's 46 years too late to change the RR.
>> Why does it have to be fixed? Other languages evolve.
>
> Yes, and either it's a total incompatible mess or else
> [more sensibly] the versions are called [eg] "K&R C", "C99", ...
> "C2x". The RR is in hard copy. We don't have magic typesetters
> to re-write history. If you want an Algol 23, contact IFIP and
> offer your services. Good luck in finding enough people with
> enough interest. It's more important to me to be able to run
> the A68 programs I've accumulated over ~50 years than to write
> a somewhat similar language with cosmetic changes and no real
> advantages. A68G will see me out; Marcus has added some
> interesting things [partial parametrisation and Torrix, amongst
> others, but sadly not yet modals] without losing backwards
> compatibility.

I just find it astonishing that after 50 years of practical use, even if
meagre, no one has ideas for enhancements. What is really that perfect?

I'd have loads. Another is to replace that 'm OF p' business with the
commonly used 'p.m', or allow both. 'm OF p' just scans badly and tends
to bleed into surrounding terms.

>> OK, my question should have been, how do you /implement/ "+" when "+"
>> meaning 'add' doesn't yet exist. There must either be some core
>> BUILT-IN features to make it practical, or "+" is secretly built-in
>> already.

No, to do you implement it in user code, not inside the compiler. Unless
I misunderstand when you said that ordinary operators like "+" and "-"
don't exist in the core language, they all have to be defined via a
prelude written in Algol68.

Then how would you write a function to add two integers, say, when "+"
does not exist.

But I guess some magic is used here.

Re: Chained comparisons A < B < C

<sms4q8$12t4$1@gioia.aioe.org>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1311&group=comp.lang.misc#1311

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!aioe.org!hzH9W6jJqCaoslGwVpYj5g.user.46.165.242.75.POSTED!not-for-mail
From: anw@cuboid.co.uk (Andy Walker)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
<smh89a$idt$1@gioia.aioe.org> <smhegt$e89$1@dont-email.me>
<smjruf$19qn$1@gioia.aioe.org> <smk08a$cvi$1@dont-email.me>
<smmhs3$1q0n$1@gioia.aioe.org> <smmno3$n4o$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="35748"; posting-host="hzH9W6jJqCaoslGwVpYj5g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2

by: Andy Walker - Sun, 14 Nov 2021 23:06 UTC

On 12/11/2021 21:53, Bart wrote:
[Algol 68:]
> I just find it astonishing that after 50 years of practical use, even
> if meagre, no one has ideas for enhancements. What is really that
> perfect?

There were then, and have been since, lots of ideas for
improvement. But you can't change Algol 68 any more than we can
change C99. There's a hint in the name. Further, Marcel's A68G
would not have been anywhere near as interesting had he not worked
very hard for compatibility with A68 as it /is/, not as /you/ might
want it to look -- esp if you propose to throw away useful syntax.
Some of the obvious enhancements have made it into A68G, such as
partial parametrisation, [parts of] Torrix, a lot of linear algebra
and other packages, a plotting library, enhancements to loops and
conditionals, interface with Linux, Curses, sound, ....

> I'd have loads. Another is to replace that 'm OF p' business with the
> commonly used 'p.m', or allow both. 'm OF p' just scans badly and
> tends to bleed into surrounding terms.

See Marcel's book, p60. But you still have to work quite
hard [or be v unlucky] to write genuine A68 that doesn't equally
work with A68G. I've managed to run a /lot/ of old programs
unchanged with A68G.

[...]
> Then how would you write a function to add two integers, say, when
> "+" does not exist.

RR10.2.3.3i. There are actually several possible ways,
some better [IMO] as pure ideas than that section of the RR;
eg you could work from the Peano axioms, or from game theory
[see Conway's book "On Numbers and Games"], or you could
implement the standard "school" method using a 3-d array
indexed by two digits and the carry, or use a version of a
fairly easy Sed script. But there's no point, as ...

> But I guess some magic is used here.
... no matter what the official definition, practical
implementations will use the "as-if" rule to replace "a+b" by
something rather like the machine code "load a, load b, add".
If you think of that as "magic", then so be it.

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

Re: Chained comparisons A < B < C

<smtrr1$ir6$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1321&group=comp.lang.misc#1321

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
<smh89a$idt$1@gioia.aioe.org> <smhegt$e89$1@dont-email.me>
<smjruf$19qn$1@gioia.aioe.org> <smk08a$cvi$1@dont-email.me>
<smmhs3$1q0n$1@gioia.aioe.org> <smmno3$n4o$1@dont-email.me>
<sms4q8$12t4$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 15 Nov 2021 14:45:54 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="be52405a544e55ee20206472d66e4640";
logging-data="19302"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18SL9VYWSGDOK7Fyb4KO8yUNEVHQvgZH1k="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Cancel-Lock: sha1:DX8rbcJ03Phl5FWdHYBi+2QK2rA=
In-Reply-To: <sms4q8$12t4$1@gioia.aioe.org>

by: Bart - Mon, 15 Nov 2021 14:45 UTC

On 14/11/2021 23:06, Andy Walker wrote:
> On 12/11/2021 21:53, Bart wrote:
> [Algol 68:]
>> I just find it astonishing that after 50 years of practical use, even
>> if meagre, no one has ideas for enhancements. What is really that
>> perfect?
>
> There were then, and have been since, lots of ideas for
> improvement. But you can't change Algol 68 any more than we can
> change C99. There's a hint in the name.

If didn't stop there being myriad versions of C, many with the their
extensions, which later became official.

>> I'd have loads. Another is to replace that 'm OF p' business with the
>> commonly used 'p.m', or allow both. 'm OF p' just scans badly and
>> tends to bleed into surrounding terms.
>
> See Marcel's book, p60.

I don't see anything like that on page 60, which seemed to be about
complex numbers. This is that 687-page PDF?

However, I did stumble cross the first program below, which is to do
with Hamming Numbers.

It made quite an impression, because it was so dreadful. Only some of
that is to do with the language; mostly just poor style.

You're trying to follow the algorithm, and it turns out most it is
defining ad hoc operators as it goes along, nothing to do with the
algorithm itself.

The definition of +:= also seems very dodgy: not just appending, but
doing something to the first part of the array too. (It doesn't need it;
it works fine with a normal append.)

My plan was to convert it into my language, but I couldn't do it. I
first refactored the A68 code, into hamm2.a68 below.

This doesn't run: mismatched something or other (I had extreme
difficulty in determining the boundaries of anything). But it was enough
to be able to finally grasp the algorithm. My version of it is in
hamm.q, below.

Hamm1.a68 only works for the first test with small numbers. Above that
it needs more memory, but I can't remember how that is done (--help said
nothing about it).

On mine, it works for the small numbers, and for 1691 (the test calls in
the book), but for 1000000, it needs bignums (use the commented line in
my version). Nothing else needs changing.

--------------------------------------------------------------------
hamm1.a68
--------------------------------------------------------------------
PR precision=100 PR
MODE SERIES = FLEX [1 : 0] UNT; # Initially, no elements #
MODE UNT = LONG LONG INT; # A 100-digit unsigned integer #
OP LAST = (SERIES h) UNT: h[UPB h]; # Last element of a series #

PROC hamming number = (INT n) UNT: # The n-th Hamming number #
CASE n
IN 1, 2, 3, 4, 5, 6, 8, 9, 10, 12 # First 10 in a table #
OUT SERIES h := 1, # Series, initially one element #
UNT m2 := 2, m3 := 3, m5 := 5, # Multipliers #
INT i := 1, j := 1, k := 1; # Counters #
TO n - 1
DO OP MIN = (INT i, j) INT: (i < j | i | j),
MIN = (UNT i, j) UNT: (i < j | i | j);
PRIO MIN = 9;
OP +:= = (REF SERIES s, UNT elem) VOID:
# Extend a series by one element, only keep the elements you need #
(INT lwb = i MIN j MIN k, upb = UPB s;
REF SERIES new s = NEW FLEX [lwb : upb + 1] UNT;
(new s[lwb : upb] := s[lwb : upb], new s[upb + 1] := elem);
s := new s
);
# Determine the n-th hamming number iteratively #
h +:= m2 MIN m3 MIN m5;
(LAST h = m2 | m2 := 2 * h[i +:= 1]);
(LAST h = m3 | m3 := 3 * h[j +:= 1]);
(LAST h = m5 | m5 := 5 * h[k +:= 1])
OD;
LAST h
ESAC;

--------------------------------------------------------------------

--------------------------------------------------------------------
hamm2.a68
--------------------------------------------------------------------
MODE UNT = LONG LONG INT; # A 100-digit unsigned integer #

OP MIN = (INT i, j) INT: (i < j | i | j);
OP MIN = (UNT i, j) UNT: (i < j | i | j);
PRIO MIN = 9;

PR precision=100 PR
MODE SERIES = FLEX [1 : 0] UNT; # Initially, no elements #

OP +:= = # Extend a series by one
element, #
BEGIN # only keep the elements you
need #
REF SERIES s, UNT elem) VOID:
(INT lwb = i MIN j MIN k, upb = UPB s;
REF SERIES news = NEW FLEX [lwb : upb + 1] UNT;
(news[lwb : upb] := s[lwb : upb], news[upb + 1] := elem);
s := news
END;

OP LAST = (SERIES h) UNT: h[UPB h]; # Last element of a series #

PROC hamming number = (INT n) UNT: # The n-th Hamming number #
BEGIN
CASE n
IN 1, 2, 3, 4, 5, 6, 8, 9, 10, 12 # First 10 in a table #
OUT
SERIES h := 1, # Series, initially one
element #
UNT m2 := 2, m3 := 3, m5 := 5, # Multipliers #
INT i := 1, j := 1, k := 1; # Counters #
TO n - 1 DO # Determine the n-th
hamming number iteratively #
h +:= m2 MIN m3 MIN m5;
IF LAST h = m2 THEN m2 := 2 * h[i +:= 1] FI;
IF LAST h = m3 THEN m3 := 3 * h[j +:= 1] FI;
IF LAST h = m5 THEN m5 := 5 * h[k +:= 1] FI
OD;
LAST h
ESAC
END

--------------------------------------------------------------------

--------------------------------------------------------------------
hamm.q
--------------------------------------------------------------------
function hamm(n) =
case n
when 1..10 then
return (1,2,3,4,5,6,8,9,10,12)[n]
else
h ::= (1,) # ::= makes a mutable copy
m2:=2; m3:=3; m5:=5
! m2:=2L; m3:=3L; m5:=5L # needed for big numbers

i := j := k := 1
to n-1 do
h append:=min(min(m2,m3),m5)
if last(h) = m2 then m2 := 2*h[++i] fi
if last(h) = m3 then m3 := 3*h[++j] fi
if last(h) = m5 then m5 := 5*h[++k] fi
od
return last(h)
esac
end
--------------------------------------------------------------------

Re: Chained comparisons A < B < C

<sn3q9g$4r2$1@gioia.aioe.org>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1336&group=comp.lang.misc#1336

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!aioe.org!hzH9W6jJqCaoslGwVpYj5g.user.46.165.242.75.POSTED!not-for-mail
From: anw@cuboid.co.uk (Andy Walker)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
<smh89a$idt$1@gioia.aioe.org> <smhegt$e89$1@dont-email.me>
<smjruf$19qn$1@gioia.aioe.org> <smk08a$cvi$1@dont-email.me>
<smmhs3$1q0n$1@gioia.aioe.org> <smmno3$n4o$1@dont-email.me>
<sms4q8$12t4$1@gioia.aioe.org> <smtrr1$ir6$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="4962"; posting-host="hzH9W6jJqCaoslGwVpYj5g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB

by: Andy Walker - Wed, 17 Nov 2021 20:56 UTC

On 15/11/2021 14:45, Bart wrote:
>>> I just find it astonishing that after 50 years of practical use, even
>>> if meagre, no one has ideas for enhancements. What is really that
>>> perfect?
>> There were then, and have been since, lots of ideas for
>> improvement. But you can't change Algol 68 any more than we can
>> change C99. There's a hint in the name.
> If didn't stop there being myriad versions of C, many with the their
> extensions, which later became official.

Yes, but the later versions of C99 weren't called C99.
Similarly, other versions of Algol were called things like A68R,
A68RS, A68S, A68C and A68G, and doubtless others I've forgotten.
If you want to invent another language called A68Bart, feel free,
but it won't gain much traction unless (a) disruption to existing
A68 programs is minimal [preferably zero], and (b) it comes with
a detailed specification saying what has changed. Meanwhile,
there will be no Algol 22 unless IFIP comes back from the dead.

>>> I'd have loads.

Note that different stropping regimes are of minimal value;
it is simple [though not trivial] to write a pre-processor [eg] to
convert between your preferred reserved-word strop and the more
usual upper-case strop. The other idea you have touted here of
zapping [most] operators and/or priorities is a no-no; too many
current programs rely on it. OTOH, if you merely want to extend
A68 go to it -- as A68G has been extended in many ways from the
language of the RR [without making existing programs useless].

>>> Another is to replace that 'm OF p' business with the
>>> commonly used 'p.m', or allow both. 'm OF p' just scans badly and
>>> tends to bleed into surrounding terms.

On the other hand, "age of person" reads better than
"person.age". It perhaps dependsnon what you're used to, and
A68 came very early into the field.

>> See Marcel's book, p60.
> I don't see anything like that on page 60, which seemed to be about
> complex numbers. This is that 687-page PDF?

My copy is 706 [ie xviii+688] pages. Section 3.8. Note
that the change is non-trivial, see the example at the bottom of
the section.

> However, I did stumble cross the first program below, which is to do
> with Hamming Numbers.
> It made quite an impression, because it was so dreadful. Only some of
> that is to do with the language; mostly just poor style.

Style wars are always unedifying, and are usually caused by
unfamiliarity with the language. If you don't like the style, you
can always run the source through a pretty-printer.

Note that the algorithm is well-known, and I would expect
any CS professional to know the problem and [at least] Dijkstra's
algorithm for solving it. There are lots of version on the web.
The one here is [allegedly] derived from a version in Python.

[...]
> The definition of +:= also seems very dodgy: not just appending, but
> doing something to the first part of the array too. (It doesn't need
> it; it works fine with a normal append.)

There is no "normal append" in Algol. That's why the program
has to (a) create a new larger array, (b) copy the old part into it,
and (c) add the new element. Feel free to write a new operator, to
go along with "min" and "max", to add to A68Bart. However, this is
a case where copying other languages too slavishly causes problems;
my own version simply created a large-enough array to start with
[e * n^(2/3) is certainly big enough, I haven't explored to see how
little I could get away with] and used it as a circular buffer.
This saved a factor of over 1500 [!] in the time taken to evaluate
the millionth Hamming number; IOW, ~99.93% of the time taken by
the transcribed Python version is taken up by steps (a,b) above.
[This is not the end of the story, as there are much more efficient
ways to calculate Hamming numbers, and there is at least another
factor of 1000 to be gained, but my (crude) program is fast enough
up to about the 10^7-th (or, at a push, 10^8-th) number.]

[...]
> Hamm1.a68 only works for the first test with small numbers. Above
> that it needs more memory, but I can't remember how that is done
> (--help said nothing about it).
$ a68g --help | grep size
--frame "number": set frame stack size to "number".
--handles "number": set handle space size to "number".
** --heap "number": set heap size to "number". **
--stack "number": set expression stack size to "number".

But that's not actually the problem, though setting the
heap larger gets further. Some versions of A68G have a bug [Gasp!
Quelle horreur! Shock!] by which garbage collection is not
initiated when it should be. My copy works, but you probably
need to call "sweep heap;" at intervals in the execution [p215
in my copy, section 10.10.7b]; "preemptive sweep" may also
work [I haven't tried it]. As above, it's all moot as you can
save many gigabytes of unnecessary allocation and copying and
thereby over 99% of the time by the simple device above.

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

Re: Chained comparisons A < B < C

<sn5k88$j8q$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=1337&group=comp.lang.misc#1337

copy link Newsgroups: comp.lang.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bc@freeuk.com (Bart)
Newsgroups: comp.lang.misc
Subject: Re: Chained comparisons A 
References: <sh27db$daf$1@dont-email.me> <sh4oi5$9on$1@dont-email.me>
<sl16s0$81o$1@dont-email.me> <sla5mf$5m2$1@dont-email.me>
<sleu53$1vb5$1@gioia.aioe.org> <slfdp6$66c$1@dont-email.me>
<slhvfu$of7$1@gioia.aioe.org> <sljah7$k6d$1@dont-email.me>
<slkccv$1r6s$1@gioia.aioe.org> <sllshp$np4$1@dont-email.me>
<slprif$1evg$1@gioia.aioe.org> <slufi4$rup$1@dont-email.me>
<sm1da5$1l2$1@gioia.aioe.org> <sm1gb4$cs$1@dont-email.me>
<sm23sk$3nb$1@gioia.aioe.org> <sm8si3$5me$1@dont-email.me>
<smcdrl$s1e$1@gioia.aioe.org> <smg116$iir$1@dont-email.me>
<smgg6a$5h7$1@gioia.aioe.org> <smgk6e$pao$1@dont-email.me>
<smh89a$idt$1@gioia.aioe.org> <smhegt$e89$1@dont-email.me>
<smjruf$19qn$1@gioia.aioe.org> <smk08a$cvi$1@dont-email.me>
<smmhs3$1q0n$1@gioia.aioe.org> <smmno3$n4o$1@dont-email.me>
<sms4q8$12t4$1@gioia.aioe.org> <smtrr1$ir6$1@dont-email.me>
<sn3q9g$4r2$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 18 Nov 2021 13:25:29 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8e02db1d927cc81d990fc1071e3896cb";
logging-data="19738"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19dV01bCALZoqg+jamku8DRtC0TDVtFvI8="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
Cancel-Lock: sha1:Blv828U77bwAyT2PxaKEbdLVl8k=
In-Reply-To: <sn3q9g$4r2$1@gioia.aioe.org>

by: Bart - Thu, 18 Nov 2021 13:25 UTC

On 17/11/2021 20:56, Andy Walker wrote:
> On 15/11/2021 14:45, Bart wrote:
>>>> I just find it astonishing that after 50 years of practical use, even
>>>> if meagre, no one has ideas for enhancements. What is really that
>>>> perfect?
>>> There were then, and have been since, lots of ideas for
>>> improvement. But you can't change Algol 68 any more than we can
>>> change C99. There's a hint in the name.
>> If didn't stop there being myriad versions of C, many with the their
>> extensions, which later became official.
>
> Yes, but the later versions of C99 weren't called C99.
> Similarly, other versions of Algol were called things like A68R,
> A68RS, A68S, A68C and A68G, and doubtless others I've forgotten.
> If you want to invent another language called A68Bart, feel free,

I did that in 1981/82! I called it M.

Now I have two languages both derived from that crude early one: a
systems language, very static, and a more dynamic scripting language.
(Although compared with Python, it might as well be static.)

Both have the same syntax inspired originally by Algol68, but as you've
seen it's more pracical with lots of tweaks.

> but it won't gain much traction

That was never the intention, which was to just to help do my job
effectively.

(And originally, it was for fun. I got a kick out of writing code in a
homemade 'HLL', on my homemade computer, that a year or two earlier
would have needed a mainframe computer.

I still get that kick.)

> On the other hand, "age of person" reads better than
> "person.age". It perhaps dependsnon what you're used to, and
> A68 came very early into the field.

I think Pascal came out not longer after (and before A68 was finalised).
That would have used 'person.age' or 'person^.age', depending on whether
'person' was a reference.

(I copied this until a couple of years ago, when I allowed the "^" to be
dropped [to match the dynamic language].

Finally moving one step nearer to A68! I decided that cleaner code was
worth the loss of transparency. But people could still add "^" if they
wanted.)

>> It made quite an impression, because it was so dreadful. Only some of
>> that is to do with the language; mostly just poor style.
>
> Style wars are always unedifying, and are usually caused by
> unfamiliarity with the language. If you don't like the style, you
> can always run the source through a pretty-printer.

In this case, it's simply poor. A pretty printer might change the layout
and indent things more consistently, but it would still leave those OP
definitions in the middle of the algorithm, or leave alone this puzzling
style of declaration (abbreviated):

SERIES h:=1, UNT m2:=2, INT i:=3;

The puzzle was the use of commas instead of semicolons to separate
distinct declarations. Even if the language allows it, you need to
consider clarity especially in a textbook aimed at people learning the
language.

> Note that the algorithm is well-known, and I would expect
> any CS professional to know the problem and [at least] Dijkstra's
> algorithm for solving it. There are lots of version on the web.
> The one here is [allegedly] derived from a version in Python.

The same program is at Rosetta Code (where it benefits a little from
colour highlighting). But looking at other languages that implement the
same algorithm, one of the clearest was AWK.

> [...]
>> The definition of +:= also seems very dodgy: not just appending, but
>> doing something to the first part of the array too. (It doesn't need
>> it; it works fine with a normal append.)
>
> There is no "normal append" in Algol.

What was odd about +:= here was that it also altered the lower-bound:
discarding earlier parts of the list that were no longer needed. That is
not something you expect from A +:= B which is usually understood to
have the same end result as A := A + B, where "+" is here meant as 'append'.

But here it does something more unusual, in not being a 'pure' function,
as you might expect for an operator, but takes account of the values of
the external i, j, k. I guess that's why it has to be inside the
algorithm, if it's a binary op.

In all, rather messy. A regular function would have been a better bet here.

Subject	Author
Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Bart
Chained comparisons A < B < C and operator precedences	James Harris
Re: Chained comparisons A < B < C and operator precedences	Bart
Re: Chained comparisons A < B < C and operator precedences	James Harris
Re: Chained comparisons A < B < C and operator precedences	Bart
Re: Chained comparisons A < B < C and operator precedences	James Harris
Re: Chained comparisons A < B < C	Charles Lindsey
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	David Brown
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	David Brown
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	David Brown
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	David Brown
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	David Brown
Re: Chained comparisons A < B < C	Rod Pemberton
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Mike Gonta
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	Andy Walker
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	Ike Naar
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Dmitry A. Kazakov
Re: Chained comparisons A < B < C	James Harris
Re: Chained comparisons A < B < C	Bart
Re: Chained comparisons A < B < C	Rod Pemberton