Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Janis Papanagnou Newsgroups: comp.lang.c Subject: Re: else ladders practice Date: Sat, 9 Nov 2024 05:51:54 +0100 Organization: A noiseless patient Spider Lines: 122 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 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 09 Nov 2024 05:51:56 +0100 (CET) Injection-Info: dont-email.me; posting-host="5b8f29fdd8d2e855fedeb808d9748089"; logging-data="3797697"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/dYgOSGrzolC7kDX5G8esl" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Cancel-Lock: sha1:JoRkAgQ5lqoojGJ8a8BEFWLWkqg= X-Enigmail-Draft-Status: N1110 In-Reply-To: Bytes: 7185 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.