Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown 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: References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org> <78eabb4054783e30968ae5ffafd6b4ff2e5a5f17@i2pn2.org> <6724CFD2.4030607@grunge.pl> <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org> 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: 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... :-) >