Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Fri, 8 Nov 2024 19:18:26 +0100
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <vglkli$3a2ej$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg0t3j$2ruor$1@dont-email.me>
 <78eabb4054783e30968ae5ffafd6b4ff2e5a5f17@i2pn2.org>
 <vg2g37$37mh3$1@dont-email.me> <6724CFD2.4030607@grunge.pl>
 <vg2llt$38ons$1@dont-email.me>
 <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org>
 <b681ee05856e165c26a5c29bf42a8d9d53843d6d@i2pn2.org>
 <vg2ttn$3a4lk$1@dont-email.me> <vg33gs$3b8n5$1@dont-email.me>
 <vg358c$3bk7t$1@dont-email.me> <vg37nr$3bo0c$1@dont-email.me>
 <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me>
 <vg62vg$3uv02$1@dont-email.me> <vg8a84$euka$1@dont-email.me>
 <vgli8o$39tog$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 08 Nov 2024 19:18:27 +0100 (CET)
Injection-Info: dont-email.me; posting-host="47bc8605b48804f4353455dfbd1c0d59";
	logging-data="3475923"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188KFKORZFiJ9CPf27jN5xQjxFHH5jzJho="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:hUy/EmymPn+Njw/ViUicvc2Mwwg=
Content-Language: en-GB
In-Reply-To: <vgli8o$39tog$1@dont-email.me>
Bytes: 5791

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