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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!novia!news-out.readnews.com!postnews3.readnews.com!not-for-mail Date: Sun, 27 Jun 2010 10:35:02 -0400 From: "Peter C. Chapin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; 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> <4c275562$0$6987$9b4e6d93@newsspool4.arcor-online.net> In-Reply-To: <4c275562$0$6987$9b4e6d93@newsspool4.arcor-online.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4c276114$0$2378$4d3efbfe@news.sover.net> Organization: SoVerNet (sover.net) NNTP-Posting-Host: b724e169.news.sover.net X-Trace: DXC=cGjofKGkemOjJkYWB:3Q7LK6_LM2JZB_C=Pfm5Z7jCNA:WUUlR<856OIaBo_]D7]AO_ On 2010-06-27 09:42, Georg Bauhaus wrote: > 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. For what it's worth, I agree that the syntax with the leading 'if' is much more readable to me than the alternatives presented here so far. For one thing (if A then B else C) seems pretty widely used by functional languages (OCaml, Haskell, Scala, even Lisp after accounting for Lisp's general syntax). It also reads well in English, which is true of other Ada constructs. In any case I want to know up front that what I'm about to read is conditional. If I have to first read over some (potentially complex) expression before I come to the syntax that signals the conditionality of the construct, I will end up back tracking and reading the expression again. Also I find that when skimming program text just knowing that something is conditional is sometimes enough for me to decide if I have to read it more closely or not. If it says X := (if Rare_Condition then Complicated_Expression else Complicated_Expression); I might be able to quickly tell which complicated expression I need to look at without having to study both. But with something like X := (Rare_Condition then Complicated_Expression else Complicated_Expression); Hera at a first glance it looks like the assignment to X is all about Rare_Condition. Something like X := (Complicated_Expression when Rare_Condition else Complicated_Expression); Is even worse. Not only does it look like the assignment is about the first complicated expression, I will probably end up studying that expression before I even realize that is only rarely evaluated. Of course it all comes down to what one is used to. Dmitry says the leading 'if' makes things harder to read, but I find his examples much more difficult. Peter