Re: else ladders practice

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

On 03.11.2024 18:00, David Brown wrote:

On 02/11/2024 21:44, Bart wrote:

>
(Note that the '|' is my example is not 'or'; it means 'then':
>
     (  c |    a )          # these are exactly equivalent
     if c then a fi
>
     (  c |    a |    )     # so are these
     if c then a else b fi
>
There is no restriction on what a and b are, statements or
expressions, unless the whole returns some value.)

>
Ah, so your language has a disastrous choice of syntax here so that
sometimes "a | b" means "or", and sometimes it means "then" or
"implies", and sometimes it means "else".

 (I can't comment on the "other use" of the same syntax in the
"poster's language" since it's not quoted here.)
 But it's not uncommon in programming languages that operators
are context specific, and may mean different things depending
on context.
 

Sure.  Just look at the comma for an overloaded syntax in many languages.

You are saying "disastrous choice of syntax". - Wow! Hard stuff.
I suggest to cool down before continuing reading further. :-)
 

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

 

Or if you feel an operator adds a lot to the
language here, why not choose one that would make sense to people, such
as "=>" - the common mathematical symbol for "implies".

 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.

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.
(For comparison, Algol 68 uses "OR", "∨" or "\/" for the "or" operator, thus it does not have this confusion.)

  From the high-level languages I used in my life I was almost
always "missing" something with conditional expressions. I
don't want separate and restricted syntaxes (plural!) in "C"
(for statements and expressions respectively), for example.
Some are lacking conditional expressions completely. Others
support the syntax with a 'fi' end-terminator and simplify
structures (and add to maintainability) supporting 'else-if'.
And few allow 'if' expressions on the left-hand side of an
assignment. (Algol 68 happens to support everything I need.
Unfortunately it's a language I never used professionally.)
 I'm positive that folks who use languages that support those
syntactic forms wouldn't like to miss them. (Me for sure.)

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

 ("disastrous syntax" - I'm still laughing... :-)