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,802ee425bbc3eba3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.132.81 with SMTP id a17mr1236100bkt.4.1335871809403; Tue, 01 May 2012 04:30:09 -0700 (PDT) Path: h15ni186348bkw.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: phil.clayton@lineone.net Newsgroups: comp.lang.ada Subject: Re: Quantified expressions: no support for restriction predicates Date: Tue, 1 May 2012 04:14:06 -0700 (PDT) Organization: http://groups.google.com Message-ID: <5737180.2760.1335870847035.JavaMail.geo-discussion-forums@vbbgl4> References: <22242340.4097.1335486547825.JavaMail.geo-discussion-forums@vbki8> <796413.773.1335612600942.JavaMail.geo-discussion-forums@vbai3> <19032073.760.1335801431421.JavaMail.geo-discussion-forums@ynlt11> NNTP-Posting-Host: 2.27.135.7 Mime-Version: 1.0 X-Trace: posting.google.com 1335871809 4715 127.0.0.1 (1 May 2012 11:30:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 1 May 2012 11:30:09 +0000 (UTC) In-Reply-To: <19032073.760.1335801431421.JavaMail.geo-discussion-forums@ynlt11> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2.27.135.7; posting-account=v7gx3AoAAABfjb9m5b7l_Lt2KVEgQBIe User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-05-01T04:14:06-07:00 List-Id: On Monday, April 30, 2012 4:57:11 PM UTC+1, Adam Beneschan wrote: > On Saturday, April 28, 2012 4:30:00 AM UTC-7, phil.c...@lineone.net wrote= : > >=20 > > Drat. I knew about the parentheses. (Personally, I would have liked p= arentheses to be required only when there is a syntactic ambiguity. I supp= ose that is so often, you may as well have them all the time.) >=20 > I have a vague memory of seeing code like this in a textbook, a long time= ago. I think it was in some version of Algol: >=20 > if if if if A then B else C then D else E then F else G then > ... >=20 > Although this isn't syntactically ambiguous, it is definitely migraine-in= ducing. Based on this, I'm glad they decided to require the parentheses. = Although code like this shouldn't be written, at least a reader would have = a fighting chance of understanding something like >=20 > if (if (if (if A then B else C) then D else E) then F else G) then I would prefer to be allowed to indent without parentheses as follows: if if if if A then B else C then D else E then F else G then ... I've probably been influenced by writing a lot of SML, which has conditiona= l expressions of the form if C then A else B (there are no statements, being a functional programming language) and the = lack of parentheses has not been an issue. Clearly Ada must force parenthe= ses in some places to avoid the dangling-else ambiguity (because "else B" i= s optional when A and B are boolean). The case I have in mind where I would like to omit parentheses is X + if C then A else B However, I would argue that parentheses should be required in (if C then A else B) + X to avoid the syntactic ambiguity. Such behaviour can probably be achieved = in a grammar (by distinguishing 'right-most' expressions and allowing condi= tional/quantified expressions in these positions to omit parentheses) but w= ould require additional expressions hierarchies in the grammar. That's a b= it complicated so I think the current approach is the most practical one. I note that reducing parentheses in future maintains compatibility with all= existing code :) Phil