Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Fri, 8 Nov 2024 18:37:26 +0100
Organization: A noiseless patient Spider
Lines: 96
Message-ID: <vgli8o$39tog$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 08 Nov 2024 18:37:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d06d34e9af5a8d1ee6a1825f8210d05f";
	logging-data="3471120"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19bxNTh3ukD8NUx6mtHumQF"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:zmyKqkpZtnKsfSdmzrQ/IHoOKJE=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <vg8a84$euka$1@dont-email.me>
Bytes: 5572

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.

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

Incidentally above syntax is what Algol 68 supports; you have
the choice to write conditionals with 'if' or with parenthesis.
As opposed to "C", where you have also *two* conditionals, one
for statements (if-then-else) and one for expressions ( ? : ),
in Algol 68 you can use both forms (sort of) "anywhere", e.g.
  IF a THEN b ELSE c FI
  x := IF a THEN b ELSE c FI
  IF a THEN b ELSE c FI := x
or using the respective alternative forms with ( a | b | c) ,
or ( a | b ) where no 'ELSE' is required. (And there's also
the 'ELIF' and the '|:' as alternative form available.)

BTW, the same symbols can also be used as an alternative form
of the 'case' statement; the semantic distinction is made by
context, e.g. the types involved in the construct.
I can understand if this sounds strange and feels unfamiliar.

> Why have a second syntax with
> a confusing choice of operators when you have a perfectly good "if /
> then / else" syntax? 

Because, depending on the program context, that may not be as
legible as the other, simpler construct.

Personally I use both forms depending on application context.
In some cases one syntax is better legible, in other cases the
other one.[*]

In complex expressions it may even be worthwhile to mix(!) both
forms; use 'if' on outer levels and parenthesis on inner levels.
(Try an example and see before too quickly dismiss the thought.)

> 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 detail of what symbols are used is
not that important to me, if it fits to the overall language
design.

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

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

Bart, out of interest; have you invented that syntax for your
language yourself of borrowed it from another language (like
Algol 68)?

Janis

[*] BTW, in Unix shell I also use the '||' and '&&' syntax
shortcuts occasionally, in addition to the if/then/else/fi
constructs, depending on the application context.