From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,334f9012742e58fc X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!xlned.com!feeder1.xlned.com!news-out2.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sun, 27 Jun 2010 15:42:58 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Gnat GPL 2010 available soon (conditional expressions) References: <2010061621145016807-sjs@essexacuk> <0fa4c574-9539-492f-8514-d32c68beb22a@w31g2000yqb.googlegroups.com> <1frrgtpa5dycl$.12kl72iqsg3dx$.dlg@40tude.net> <4c270613$0$6974$9b4e6d93@newsspool4.arcor-online.net> <1wuwvzgwlwgli$.1birkinieia0d$.dlg@40tude.net> <1ur19ais2ejih.mjbgdsv9pr66.dlg@40tude.net> In-Reply-To: <1ur19ais2ejih.mjbgdsv9pr66.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4c275562$0$6987$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 27 Jun 2010 15:42:58 CEST NNTP-Posting-Host: 0b4ef92e.newsspool4.arcor-online.net X-Trace: DXC=oJ^2jeid5PTaoembcbF;DQ4IUKejVXJ7H\_854F2]D]h>P67?F\_ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:12921 Date: 2010-06-27T15:42:58+02:00 List-Id: On 6/27/10 2:12 PM, Dmitry A. Kazakov wrote: > On Sun, 27 Jun 2010 03:55:02 -0700 (PDT), lekktu@gmail.com wrote: > >> On Jun 27, 10:37 am, "Dmitry A. Kazakov" >> wrote: >> >>> dropped "if", because you don't need it: >>> >>> (A then B [else C]) >>> >>> is syntactically unambiguous and easier to read. >> >> As you can see on the relevant AI, this was in fact considered (among >> lots of other things). FWIW, I'm quite glad they went for the 'if', to >> me it is *much* easier to read. > > How do you know it? (:-)) I'd know readability of some particular syntax from empirical evidence. People read statements. How many times do you hear someone shout, "Ouch, this is conditional, I didn't notice at first!" Cases in point are when a declaration or a statement does not start with IF but involves a conditional expression. Compare alternative solutions.[*] (I believe Dilbert explains some kind of WTF count for quality testing but I can't find it at the moment.) The situation is worse in the functional languages camp, though. Whitaker's observations from the mid 1970s become true again there, I think. If you have to select software components by functionality you must still accept it when each is written in some new language, because ... That's where Whitaker's observations are relevant again, I think. Python has your syntax, too, though it didn't from the start, see about PEP 308, where Kuchling writes, "so the order of evaluation jumps around a bit": The expression B if A else C places the controlling expression in the middle of what it is controlling. This placement seem obvious when painting program trees but we are writing programs on single lines. When you read linearly, IF will signal that some case distinction is coming. When IF appears after what it is controlling, you are reminded that what you have just been reading is actually conditional on some program text to follow next. And maybe there is going to be some other thing for the other case. Or maybe not. More about the parens around the expressions in Kuchling's comments, too. Python also has [F(X) for X in I if P] for list comprehensions, I being iterable. No else part is allowed here. Compare [ F(X) : X in I | P ] of SETL (or { F(X) ... } for set comprehensions) and [ F(X) | X <- I, P ] of Haskell. There are more syntactic variations of the same concept of a list comprehension in every journeyman's piece being added as a new programming language to the list of yet another functional programming language. No one seems to ask the question that had obviously been asked when Algol 60 was created: What is the abstract syntax for this and how can we make a good, satisfying concrete syntax? Based on which criteria? Python also has A and B or C meaning the same as "B if A else C". This works because all expressions can be used as Booleans. Anyway, Python is said to be consistent, probably because of the supply of rules about proper contexts for using the word "if". Now add to that single rule set the requirement to use more than one language during daily work, each of them equipped with IF related idiosyncrasies. Makes me mad. If conditional expressions are needed, then at least let the reader know that what is next is a conditional. Ada uses the token sequence '(', IF for that. Kuchling recommends parens for Python's conditional expressions even when they are not strictly needed; they are when sorting out associativity problems. http://docs.python.org/whatsnew/2.5.html This is the version of Python that programming Google App Engine currently requires... ____ [*] Always important for for a language being capable of drawing attention: Is the equation "easy syntax" = "dumb and boring" true? If so, we have to provide for some ASCII punctuation shuffling in the grammar, because these are the characters that programmers are capable of typing on their keyboards. There sole means of distinction. See MS's answer called F#, BTW...