On 04/04/2024 15:50, Chris Elvidge wrote:
> On 03/04/2024 at 08:38, David Brown wrote:
>> One lottery winner managed this.  When he won about £160M in the
>> lottery, he bought his favourite football club (or "soccer club", for
>> those who come from a country where "football" doesn't involve feet or
>> round balls) and set it up as a trust owned by the club's fans.
>
> I do wish people would stop intimating that the US is the only place
> where Association Football (the football we play in the UK) is known as
> soccer. When I was at secondary school (back in the 1960's) "soccer
> practise" was a well know alternative to the term "football practise".
>

The term "soccer" is sometimes used in the UK, yes. It is most common
in schools or areas of the country where rugby (also occasionally known
as "Rugby Football") is popular.

But the term "football", unqualified, invariably means "soccer" - except
in the USA.

On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:

> And let me tell you, when you start getting into that kind of nested
> stuff with not parentheses in view, even the "?:" notation can start
> looking pretty darn mysterious to some folks.

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>
>> And let me tell you, when you start getting into that kind of nested
>> stuff with not parentheses in view, even the "?:" notation can start
>> looking pretty darn mysterious to some folks.
>
>This is where indentation helps. E.g.
>
> a =
> b ?
> c ? d : e
> : f ?
> g ? h : i
> : j;

Just use brackets. Saves a lot of pain.

Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 09:17 this Friday (GMT):
> On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>>
>>> And let me tell you, when you start getting into that kind of nested
>>> stuff with not parentheses in view, even the "?:" notation can start
>>> looking pretty darn mysterious to some folks.
>>
>>This is where indentation helps. E.g.
>>
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

Or just use if blocks if it's too complex.
--
user <candycane> is generated from /dev/urandom

On Fri, 5 Apr 2024 12:40:02 -0000 (UTC)
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
>Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 09:17 this Friday
>(GMT):
>> On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>>>
>>>> And let me tell you, when you start getting into that kind of nested
>>>> stuff with not parentheses in view, even the "?:" notation can start
>>>> looking pretty darn mysterious to some folks.
>>>
>>>This is where indentation helps. E.g.
>>>
>>> a =
>>> b ?
>>> c ? d : e
>>> : f ?
>>> g ? h : i
>>> : j;
>>
>> Just use brackets. Saves a lot of pain.
>
>
>Or just use if blocks if it's too complex.

Indeed. It might not look as "l33t", but with modern compilers it'll end
up as the same assembler anyway.

On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:
> On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>
>> And let me tell you, when you start getting into that kind of nested
>> stuff with not parentheses in view, even the "?:" notation can start
>> looking pretty darn mysterious to some folks.
>
> This is where indentation helps. E.g.
>
> a =
> b ?
> c ? d : e
> : f ?
> g ? h : i
> : j;
>

Indentation generally helps. In above code (in my book) it's not
that clear [from the indentation], e.g. where the last ':' 'else'
belongs to. So I'd have lined the colons up with the respective
'?'. (YMMV.)

Not all languages differentiate (per syntax) a conditional command
from a conditional expression. Here are the two forms supported by
Algol for both, statements and expressions (here the examples are
both depicted for expressions only)

a :=
( b | ( c | d | e )
| ( f | ( g | h | i )
| j ) );

The parenthesis are not used for grouping, but are the alternative
form for IF/THEN/ELSE/FI

a := IF b
THEN
IF c THEN d ELSE e FI
ELSE
IF f THEN
IF g THEN h ELSE i FI
ELSE j FI
FI

Pick your choice depending on the case (or taste).

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:
>On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:
>>This is where indentation helps. E.g.
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>>
>Indentation generally helps.

Let me give it a try to find how I would indent that!

b?
c? d: e:
f?
g? h: i:
j;

>The parenthesis are not used for grouping, but are the alternative
>form for IF/THEN/ELSE/FI

It's funny how the discussion oscillates between
"too many parentheses" (LISP code) and "not enough parentheses"
("let me add some parens to improve readability").

On 2024-04-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:
>> On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>>
>>> And let me tell you, when you start getting into that kind of nested
>>> stuff with not parentheses in view, even the "?:" notation can start
>>> looking pretty darn mysterious to some folks.
>>
>> This is where indentation helps. E.g.
>>
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>>
>
> Indentation generally helps. In above code (in my book) it's not
> that clear [from the indentation], e.g. where the last ':' 'else'
> belongs to. So I'd have lined the colons up with the respective
> '?'. (YMMV.)
>
> Not all languages differentiate (per syntax) a conditional command
> from a conditional expression. Here are the two forms supported by
> Algol for both, statements and expressions (here the examples are
> both depicted for expressions only)
>
> a :=
> ( b | ( c | d | e )
> | ( f | ( g | h | i )
> | j ) );
>
> The parenthesis are not used for grouping, but are the alternative
> form for IF/THEN/ELSE/FI
>
> a := IF b
> THEN
> IF c THEN d ELSE e FI
> ELSE
> IF f THEN
> IF g THEN h ELSE i FI
> ELSE j FI
> FI
>
> Pick your choice depending on the case (or taste).

#define XCAT(A, B) A ## B
#define CAT(A, B) XCAT(A, B)

#define IF(A, B, C) ((A) ? (B) : (C))

#define COND_2(cond, then, ...) IF(cond, then, 0)
#define COND_4(cond, then, ...) IF(cond, then, COND_2(__VA_ARGS__))
#define COND_6(cond, then, ...) IF(cond, then, COND_4(__VA_ARGS__))
#define COND_8(cond, then, ...) IF(cond, then, COND_6(__VA_ARGS__))

#define COND_1(...) {syntax error}
#define COND_3(...) {syntax error}
#define COND_5(...) {syntax error}
#define COND_7(...) {syntax error}

#define COUNT_ARGS(...) COUNT_ARGS_IMPL(__VA_ARGS__, 8, 7, 6, 5, 4, 3, 2, 1)
#define COUNT_ARGS_IMPL(_1, _2, _3, _4, _5, _6, _7, _8, N, ...) N

#define COND(...) CAT(COND_, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)

Now we can do:

COND(b, ...,
f, ...
1, j)

filling in the ...:

COND(b, IF(c, d, e),
f, IF(g, h, i),
1, j)

The GNU preprocessor gives me this:

((b) ? (((c) ? (d) : (e))) : (((f) ? (((g) ? (h) : (i))) : (((1) ? (j) : (0))))))

which looks correct.

The code is readable now, and importantly, my editor can format it. If I
start adding line breaks, it's indented right. If I turn it into this:

COND(b, IF(c, d, e),
f, IF(g, h, i),
1, j)

then highlight it in Vim and hit =, it gets put back the way it was.

If I add line breaks into the IFs, they get automatically indented
right, just using Vim's support for basic C formatting of macro/function
calls:

cond(b, IF(c,
d,
e),
f, IF(g,
h,
i),
1, j)

Compared to wrestling with five ways of formatting the the ill-conceived
?: syntax, it's a complete no brainer.

Here is a version where the cond pairs have to be parenthesized.
We can lose the even/odd argument count handling, and might as well
extend to up to 8 clauses:

#define IF(A, B, C) ((A) ? (B) : (C))

#define XCAT(A, B) A ## B
#define CAT(A, B) XCAT(A, B)

#define COND_PAIR(pair, rest) IF(COND_COND pair, COND_THEN pair, rest)
#define COND_COND(cond, then) cond
#define COND_THEN(cond, then) then
#define COND_1(pair, ...) COND_PAIR(pair, 0)
#define COND_2(pair, ...) COND_PAIR(pair, COND_1(__VA_ARGS__))
#define COND_3(pair, ...) COND_PAIR(pair, COND_2(__VA_ARGS__))
#define COND_4(pair, ...) COND_PAIR(pair, COND_3(__VA_ARGS__))
#define COND_5(pair, ...) COND_PAIR(pair, COND_4(__VA_ARGS__))
#define COND_6(pair, ...) COND_PAIR(pair, COND_5(__VA_ARGS__))
#define COND_7(pair, ...) COND_PAIR(pair, COND_6(__VA_ARGS__))
#define COND_8(pair, ...) COND_PAIR(pair, COND_7(__VA_ARGS__))

#define COUNT_ARGS(...) COUNT_ARGS_IMPL(__VA_ARGS__, 8, 7, 6, 5, 4, 3, 2, 1)
#define COUNT_ARGS_IMPL(_1, _2, _3, _4, _5, _6, _7, _8, N, ...) N

#define COND(...) CAT(COND_, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)

COND((b, IF(c,
d,
d)),
(f, IF(g,
h,
i)),
(1, j))

The expansion is still

((b) ? (((c) ? (d) : (d))) : (((f) ? (((g) ? (h) : (i))) : (((1) ? (j) : (0))))))

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Fri, 5 Apr 2024 18:30:12 +0200, Janis Papanagnou wrote:

> Here are the two forms supported by Algol ...

Just a note, that’s Algol 68. In my time, “Algol” used unqualified was
understood to refer to Algol 60.

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:

> On Thu, 4 Apr 2024 23:29:21 -0000 (UTC) Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote:
>>
>>This is where indentation helps. E.g.
>>
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

The improvement speaks for itself.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
...
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

A normal programmer would write something like:

a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;

I.e., she would allow herself to use spaces and newlines, and just
enough parentheses to make the structure clear.

- Alan

On Fri, 05 Apr 2024 19:35:37 -0400, Alan Bawden wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
> ...
> >> a =
> >> b ?
> >> c ? d : e
> >> : f ?
> >> g ? h : i
> >> : j;
> >
> > Just use brackets. Saves a lot of pain.
>
> a=(b?(c?d:e):(f?(g?h:i):j));
>
> A normal programmer would write something like:
>
> a = b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>
> I.e., she would allow herself to use spaces and newlines, and just
> enough parentheses to make the structure clear.

It’s like, I don’t know ... you’re trying to save space. Why?

It’s like programming inside an apartment block, instead of having a
bungalow with a yard of your own.

On 2024-04-05, Alan Bawden <alan@csail.mit.edu> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
> ...
> >> a =
> >> b ?
> >> c ? d : e
> >> : f ?
> >> g ? h : i
> >> : j;
> >
> > Just use brackets. Saves a lot of pain.
>
> a=(b?(c?d:e):(f?(g?h:i):j));
>
> A normal programmer would write something like:
>
> a = b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>
> I.e., she would allow herself to use spaces and newlines, and just
> enough parentheses to make the structure clear.

It looks good, undeniably.

However, I cannot tell at a glance whether or not the nice appearance
isn't telling me some kind of lie. That's an inherent problem with
the ternary operator.

I have to remember that = has lower precedence than ?:. But, ==
has higher precedence. So this careless edit makes it wrong,
even though it still looks just as nice:

a == b ? (c ? d : e) :
f ? (g ? h : i) :
j;

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 15:09 this Friday (GMT):
> On Fri, 5 Apr 2024 12:40:02 -0000 (UTC)
> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
>>Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 09:17 this Friday
>>(GMT):
>>> On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>>>>
>>>>> And let me tell you, when you start getting into that kind of nested
>>>>> stuff with not parentheses in view, even the "?:" notation can start
>>>>> looking pretty darn mysterious to some folks.
>>>>
>>>>This is where indentation helps. E.g.
>>>>
>>>> a =
>>>> b ?
>>>> c ? d : e
>>>> : f ?
>>>> g ? h : i
>>>> : j;
>>>
>>> Just use brackets. Saves a lot of pain.
>>
>>
>>Or just use if blocks if it's too complex.
>
> Indeed. It might not look as "l33t", but with modern compilers it'll end
> up as the same assembler anyway.

Yeah. Not everything needs to be a hyper optimized single line
statement.
--
user <candycane> is generated from /dev/urandom

Alan Bawden <alan@csail.mit.edu> wrote at 23:35 this Friday (GMT):
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
> ...
> >> a =
> >> b ?
> >> c ? d : e
> >> : f ?
> >> g ? h : i
> >> : j;
> >
> > Just use brackets. Saves a lot of pain.
>
> a=(b?(c?d:e):(f?(g?h:i):j));
>
> A normal programmer would write something like:
>
> a = b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>
v (she?)
> I.e., she would allow herself to use spaces and newlines, and just
> enough parentheses to make the structure clear.
>
> - Alan

Yeah, a bit of space for the code to breathe goes a long way.
--
user <candycane> is generated from /dev/urandom

On 5 Apr 2024 17:37:52 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:
>>On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:
>>>This is where indentation helps. E.g.
>>> a =
>>> b ?
>>> c ? d : e
>>> : f ?
>>> g ? h : i
>>> : j;
>>>
>>Indentation generally helps.
>
> Let me give it a try to find how I would indent that!
>
>b?
> c? d: e:
> f?
> g? h: i:
> j;
>
>>The parenthesis are not used for grouping, but are the alternative
>>form for IF/THEN/ELSE/FI
>
> It's funny how the discussion oscillates between
> "too many parentheses" (LISP code) and "not enough parentheses"
> ("let me add some parens to improve readability").

Lisp overloads them as block markers which simply makes the code more
confusing, not less.

On Fri, 05 Apr 2024 19:35:37 -0400
Alan Bawden <alan@csail.mit.edu> wrote:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
> ...
> >> a =
> >> b ?
> >> c ? d : e
> >> : f ?
> >> g ? h : i
> >> : j;
> >
> > Just use brackets. Saves a lot of pain.
>
> a=(b?(c?d:e):(f?(g?h:i):j));
>
>A normal programmer would write something like:
>
> a = b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>
>I.e., she would allow herself to use spaces and newlines, and just

ITYM "he" would allow HIMself.

Lets give the woke BS a miss, 95% of developers are men. It doesn't give you
any brownie points, just makes you look a try-hard ass.

On 06/04/2024 03:01, Kaz Kylheku wrote:
> On 2024-04-05, Alan Bawden <alan@csail.mit.edu> wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
>> ...
>> >> a =
>> >> b ?
>> >> c ? d : e
>> >> : f ?
>> >> g ? h : i
>> >> : j;
>> >
>> > Just use brackets. Saves a lot of pain.
>>
>> a=(b?(c?d:e):(f?(g?h:i):j));
>>
>> A normal programmer would write something like:
>>
>> a = b ? (c ? d : e) :
>> f ? (g ? h : i) :
>> j;
>>
>> I.e., she would allow herself to use spaces and newlines, and just
>> enough parentheses to make the structure clear.
>
> It looks good, undeniably.
>
> However, I cannot tell at a glance whether or not the nice appearance
> isn't telling me some kind of lie. That's an inherent problem with
> the ternary operator.

That's a key point - and it is not just with the ternary operator, but a
general issue. Good spacing, indentation, newlines and layout make code
easier to read. But it is vital that there is never any doubt that the
layout matches the meaning of the code. If not, then you might be sure
what the programmer meant dues to the layout, but you are not sure that
the compiler sees it the same way. After all, this looks neat and clear
too :

a =
b & c +
d & e +
f & g

But the language viewpoint (assuming it is in C, or a language with
similar precedences) and the code appearance are very different.

Parentheses help, until there are too many to be easily tracked by the
reader. Splitting the expression into parts, adding new local
variables, using separate statements, making new helper functions -
these are all ways to improve the code, and have no efficiency cost with
modern tools.

A lot of people think the layout of code should make the programmer's
intentions clear, and make it easy to see what the code does. That's
true, but it is not enough. Code layout should also make it easy to see
that the code does what the programmer intended. It should be easy for
a maintainer to modify it without introducing errors. It should also be
hard for a reader to misinterpret it (which is not the same as saying it
should be easy to interpret correctly). It should be hard for a
maintainer to make mistakes. It should be easy to spot any mistakes
that get made.

>
> I have to remember that = has lower precedence than ?:. But, ==
> has higher precedence. So this careless edit makes it wrong,
> even though it still looks just as nice:
>
> a == b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>

On Sat, 6 Apr 2024 15:44:13 +0200
David Brown <david.brown@hesbynett.no> wrote:
>A lot of people think the layout of code should make the programmer's
>intentions clear, and make it easy to see what the code does. That's

Unfortunately IME another lot (usually young) seem to think that the more
complicated their make their code the more it will impress their peers and/or
boss. This seems to be a particular problem with C++ as its current overspecced
and overcomplicated syntax allows you to write code that would make a Perl dev
envious.

On 05.04.2024 19:37, Stefan Ram wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:
>>
>> [ Algol syntax variants, keywords vs. parenthesis ("meek form" ?) ]
>
>> The parenthesis are not used for grouping, but are the alternative
>> form for IF/THEN/ELSE/FI
>
> It's funny how the discussion oscillates between
> "too many parentheses" (LISP code) and "not enough parentheses"
> ("let me add some parens to improve readability").

We should distinguish the various aspects posted over time.
Parenthesis used...
- to group sub-expressions (to make precedence clear or
fix some precedence inconsistency in the language)
=> that's IMO a Good Thing for non-trivial cases
- as necessary syntax of the language (like inherently
in Lisp, or in C's control structures)
=> I don't like them, but you have no choice here
(but changing the language, where/if possible)
- as an alternative syntactic form of conditionals
(as in Algol, where you can choose the syntax)
=> Personally I like the verbose keywords, but in
case of conditional expressions the concise form
with parenthesis might be better readable (though
this can be different in complex cases as posted)
Note that in Algol not only the 'IF's can be written
in that parenthesis syntax form, you can also use
the '(' and ')' instead of the 'BEGIN'/'END' keywords.

It boils down to: to each his own, and, use what's most
appropriate depending on context.

Janis

On 06.04.2024 01:08, Lawrence D'Oliveiro wrote:
> On Fri, 5 Apr 2024 18:30:12 +0200, Janis Papanagnou wrote:
>
>> Here are the two forms supported by Algol ...
>
> Just a note, that’s Algol 68. In my time, “Algol” used unqualified was
> understood to refer to Algol 60.

This seems to have been the case before Algol 68 appeared.
(I'm not sure this matches with what you call "in my time".)

I named it always explicitly as "Algol 60" and "Algol 68".
But at some instance of time I read somewhere that "Algol"
would "now" refer to Algol 68, so I changed my habit.

But since your post shows that this may not (not yet?) be
common usage I'll be more specific in future. - Thanks for
the hint!

Janis

On 06/04/2024 17:57, Janis Papanagnou wrote:
> I named it always explicitly as "Algol 60" and "Algol 68".
> But at some instance of time I read somewhere that "Algol"
> would "now" refer to Algol 68, so I changed my habit.

Quite right. Algol 60 died, for all practical purposes,
half a century ago. Algol 68 may be a niche interest, but it is
still a nice language, and its [dwindling] band of adherents and
practitioners still use it and prefer it to C and other more
recent languages.

> But since [LD'O's] post shows that this may not (not yet?) be
> common usage I'll be more specific in future. - Thanks for
> the hint!

For how long? Does anyone still think that an unadorned
"Unix" must refer to 6th Edition [or earlier], "C" to K&R, "Fortran"
to Fortran IV, and so on? Clearly, there /are/ occasions when it is
necessary to specify which version of a language/OS/computer/... is
being referred to, and there is often a change-over period of a few
years when an older version is still sufficiently current. But fifty
years is surely long enough to get used to the newer version!

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

On 06.04.2024 20:32, Andy Walker wrote:
> On 06/04/2024 17:57, Janis Papanagnou wrote:
>> I named it always explicitly as "Algol 60" and "Algol 68".
>> But at some instance of time I read somewhere that "Algol"
>> would "now" refer to Algol 68, so I changed my habit.
>
> Quite right. Algol 60 died, for all practical purposes,
> half a century ago. Algol 68 may be a niche interest, but it is
> still a nice language, and its [dwindling] band of adherents and
> practitioners still use it and prefer it to C and other more
> recent languages.

I think it's a not only formally outstanding language; despite I've
never used it professionally since my first contact with it in the
early 1980's. (Though I still have a compiler on my private box to
play with it.)

>
>> But since [LD'O's] post shows that this may not (not yet?) be
>> common usage I'll be more specific in future. - Thanks for
>> the hint!
>
> For how long? Does anyone still think that an unadorned
> "Unix" must refer to 6th Edition [or earlier], "C" to K&R, "Fortran"
> to Fortran IV, and so on? Clearly, there /are/ occasions when it is
> necessary to specify which version of a language/OS/computer/... is
> being referred to, and there is often a change-over period of a few
> years when an older version is still sufficiently current. But fifty
> years is surely long enough to get used to the newer version!

Yes. - What I didn't know was whether that generic "Algol" naming
convention was already made around 1968 or maybe only much later.

But, WRT Algol 60 vs. Algol 68, these are quite different languages;
I wouldn't call the latter a new version. While some basic abstract
concepts from Algol 60 have certainly been considered in Algol 68
the whole design and specification process was done anew in Algol 68.
(The van Wijngaarden grammar also was some fundamental new approach.)
These languages can hardly be seen as "versions" of the same language.

Algol 60, OTOH, also had an own history and continued use after 1968;
to my knowledge it had been used in numerical mathematics and it was
(while per se quite terse a language) the base of Simula 67, an
extremely powerful language ahead of time (still).

But Algol 60, Simula, and also Algol 68 are all meaningless today, I
(sadly) dare to say. Maybe more than of "niche interest"? Can't tell.
Back these days they certainly were not hyped (as languages nowadays
are as part of the inventor's "marketing" activities). There's papers
existing that try to explain the/possible reasons for their fail to
become established.

Janis

Andy Walker <anw@cuboid.co.uk> writes:
> On 06/04/2024 17:57, Janis Papanagnou wrote:
>> I named it always explicitly as "Algol 60" and "Algol 68".
>> But at some instance of time I read somewhere that "Algol"
>> would "now" refer to Algol 68, so I changed my habit.

That doesn't match my experience.

> Quite right. Algol 60 died, for all practical purposes,
> half a century ago. Algol 68 may be a niche interest, but it is
> still a nice language, and its [dwindling] band of adherents and
> practitioners still use it and prefer it to C and other more
> recent languages.

I've never heard "Algol" by itself used to refer to Algol 68, which had
enough changes to be essentially a different language, and one which
didn't really replace Algol 60 (though it was clearly intended to).

<https://en.wikipedia.org/wiki/ALGOL> agrees.

The relative popularity of Algol 60 vs. 68 doesn't necessarily change
what "Algol" means.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Sat, 6 Apr 2024 18:57:47 +0200, Janis Papanagnou wrote:

> I named it always explicitly as "Algol 60" and "Algol 68". But at some
> instance of time I read somewhere that "Algol" would "now" refer to
> Algol 68, so I changed my habit.

Sure, Algol 60 is way beyond a museum piece by now. But remember, that was
the one that spawned a great number of offshoots, namely the “Algol-like”
language family--or really, superfamily. That included Pascal and its own
offshoots.

Algol 68 was a bit less influential in terms of language features (I think
C “int”, “char”, “struct” and “union”, and the “long” and “short”
qualifiers came from there, and csh “if ... fi” as well), but it did seem
to introduce a bunch of new terminology, some of which caught on, others
did not. See how many you can spot:

* “Elaboration” for the process of executing a program (including possibly
transforming from source form to an executable form)
* “Transput” instead of “input/output”
* “Heap” for an area in which memory may be dynamically allocated and
freed in no particular order
* “Overloading” for multiple context-dependent definitions of an operator
* “Name” instead of “pointer” or “address”
* “Mode” instead of “data type”
* “Coercion” for a type conversion
* “Cast” for an explicit type conversion
* “Void” for a construct yielding no value
* “Dereferencing” for following a pointer
* “Slice” for a subarray of an array
* “Pragmat” for compiler directive (I think “pragma” is more common
nowadays.)