Re: else ladders practice

On 08.11.2024 19:18, David Brown wrote:

On 08/11/2024 18:37, Janis Papanagnou wrote:

The | operator means "or" in the OP's language (AFAIK - only he actually
knows the language).  So "(a | b | c)" in that language will sometimes
mean the same as "(a | b | c)" in C, and sometimes it will mean the same
as "(a ? b : c)" in C.

As said ("I can't comment on the "other use" of the same syntax"),
I don't know Bart's language, so cannot comment on that.

And, frankly, some personal language projects are not of interest
to me, apart from experiences the implementer (Bart) has gotten
from his projects that might be worthwhile to consider for other
languages' evolution or design. This is why I got interested in
the thread and his posts.

 
There may be some clear distinguishing feature that disambiguates these
uses.  But this is a one-man language - there is no need for a clear
syntax or grammar, documentation, consistency in the language, or a
consideration for corner cases or unusual uses.

Incidentally above syntax is what Algol 68 supports;

 
Yes, he said later that Algol 68 was the inspiration for it.  Algol 68
was very successful in its day - but there are good reasons why many of
its design choices were been left behind long ago in newer languages.

Myself I've never seen Algol 68 code outside of education and
specification. (But that's normal due my naturally restricted
view on what happens all over the world. So if you have some
examples for practical successes of Algol 68 I'd be interested
to hear about.)

Some design decisions of Algol 68 are arguable, indeed, and we
can observe that from the reports those days. (But that's not
surprising given that there have been a lot of different (and
strong) characters, university professors and scientists from
all over the world, in the committees and working group.) It's
obvious that quite some members left and introduced their own
languages; those languages were of course also not unopposed.

I don't think, though, that this natural segregation process or
any design decisions of some later developed languages would
give evidence for a clear negative valuation of any specific
language details (or for the language as a whole). Contrary,
a lot of later languages even ignored outstanding and important
concepts of languages these days. (The market and politics have
their own logic and dynamics.)

>
This is as opinion of course arguable. It's certainly also
influenced where one is coming from (i.e. personal expertise
from other languages).

 
The language here is "mathematics".  I would not expect anyone who even
considers designing a programming language to be unfamiliar with that
symbol.

Mathematics, unfortunately, [too] often has several symbols for
the same thing. (It's in that respect not very different from
programming languages, where you can [somewhat] rely on + - * /
but beyond that it's getting more tight.)

Programming languages have the additional problem that you don't
have all necessary symbols available, so language designers have
to map them onto existing symbols. (Also Unicode in modern times
do not solve that fact, since languages typically rely on ASCII,
or some 8-bit extension, at most; full Unicode support, I think,
is rare, especially on the lexical language level. Some allow
them in strings, some in identifiers; but in language keywords?)

BTW, in Algol 68 you can define operators, so you can define
"OP V" or "OP ^" (for 'or' and 'and', respectively, but we cannot
define (e.g.) "OP ·" (a middle dot, e.g. for multiplication).[*]

 

The detail of what symbols are used is
not that important to me, if it fits to the overall language
design.

 
I am quite happy with the same symbol being used for very different
meanings in different contexts.  C's use of "*" for indirection and for
multiplication is rarely confusing.  Using | for "bitwise or" and also
using it for a "pipe" operator would probably be fine - only one
operation makes sense for the types involved.  But here the two
operations - "bitwise or" (or logical or) and "choice" can apply to to
the same types of operands.  That's what makes it a very poor choice of
syntax.

Well, I'm more used (from mathematics) to 'v' and '^' than to '|'
and '&', respectively. But that doesn't prevent me from accepting
other symbols like '|' to have some [mathematical] meaning, or
even different meanings depending on context. In mathematics it's
not different; same symbols are used in different contexts with
different semantics. (And there's also the mentioned problem of
non-coherent literature WRT used mathematics' symbols.)

 
(For comparison, Algol 68 uses "OR", "∨" or "\/" for the "or" operator,
thus it does not have this confusion.)

Actually, while I like Algol 68's flexibility, there's in some
cases (to my liking) too many variants. This had partly been
necessary, of course, due to the (even more) restricted character
sets (e.g. 6-bit characters) available in the 1960's.

The two options for conditionals I consider very useful, though,
and it also produces very legible and easily understandable code.

[...]

 
I've nothing (much) against the operation - it's the choice of operator
that is wrong.

Well, on opinions there's nothing more to discuss, I suppose.

Janis

[*] Note: I'm using the "Genie" compiler for tests.