Re: Quantified expressions: no support for restriction predicates

[phil.clayton@lineone.net]

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:
> > 
> > Drat.  I knew about the parentheses.  (Personally, I would have liked parentheses to be required only when there is a syntactic ambiguity.  I suppose that is so often, you may as well have them all the time.)
> 
> 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:
> 
>    if if if if A then B else C then D else E then F else G then
>       ...
> 
> Although this isn't syntactically ambiguous, it is definitely migraine-inducing.  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
> 
>    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 conditional 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 parentheses in some places to avoid the dangling-else ambiguity (because "else B" is 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 conditional/quantified expressions in these positions to omit parentheses) but would require additional expressions hierarchies in the grammar.  That's a bit 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