Re: [PATCH] Add 'switch' statement to match.pd language

[Richard Biener <rguenther@suse.de>]

On Wed, 15 Jul 2015, Michael Matz wrote:

> Hi,
> 
> On Wed, 15 Jul 2015, Richard Biener wrote:
> 
> > >>  (switch
> > >>   (A) B
> > >>   (B) C
> > >>   (C) D
> > >>   E)
> > >
> > >The lispy way would have been
> > >
> > >   (switch
> > >    (A) (B)
> > >    (C) (D)
> > >    (E) (F)
> > >    G)
> > >
> > >i.e. parenthesize the result as well, which then would be unambiguously
> > 
> > That's just atoms vs. Expressions.
> 
> But if the result is no atom, you'd want parentheses.  Similar if the 
> condition is no expression but an atom, you'd want to leave out 
> parentheses as well.  My point is, that both condition and result are at 
> the same level, and hence should be subject to the same parenthesis rules, 
> namely: surrounding parens by default, optional for atoms.
> 
> > Like (Plus @0 @1) vs. Plain @1.  So you suggest to require ((plus @0 
> > @1)) here to make it unambiguous?
> 
> No :)  Just look at your example again:
> 
>  (switch
>   (A) B
>  )
> 
> Both A and B are at the same level, and are both expressions, but still 
> you parenthesize them differently; that can't be right.  You also don't 
> write
> 
>  (switch
>   ((plus @0 @1))  (@0)
>  )
> 
> You write
> 
>  (switch
>   (plus @0 @1) (@0)
>  )
> 
> And as syntactic sugar you are allowed to leave out the parens around @0 
> as it's an atom:
> 
>  (switch
>   (plus @0 @1) @0
>  )
> 
> Similar, if the condition is an atom you should be able to leave the 
> parens away:
> 
>  (switch
>   cond (minus @0 @1)
>  )
> 
> (given a predicate 'cond' defined appropriately).

Yes.  Though techincally the condition cannot be an atom because
it has to be a c-expr and that has no notion of atom vs. no-atom.

But the issue is to unambiguously parse the else clause, thus

 (switch
  (integer_zerop (@0)) (plus @1 @2)   <--- if - then
  (integer_onep (@0)) (minus @2 @1)   <--- if - then
  (minus @3 @2))                      <--- else

whether or not the then or else clauses are atoms.  The parser
currently cannot backtrack and optimistically parse the next
expression or atom as 'else' and fall back to 'if' (a condition)
if that fails.  The parser has to know upfront by peeking at N
tokens whether the next entry of the switch is a if - then or
the else.

Thus the extra "redundant" keyword.

Richard.