Hello Manuel, this is exactly the change that is being discussed: currently a `case` expression is not considered to be atomic (`aexp`), which is why it can't appear in a record update without parens.
The proposed change, as I understand it, is to make `case` (and `do`) into atomic expressions as they are "parentesized" by the key-word (`case` or `do`) at the start, and the closing `}` at the end. Making this change would allow the kind of thing you were expecting, which to me makes sense. Others seem to find it confusing :-) -Iavor On Wed, Jul 13, 2016 at 10:35 AM, Manuel Gómez <tar...@gmail.com> wrote: > On Wed, Jul 13, 2016 at 5:42 AM, C Maeder <chr.mae...@web.de> wrote: > > seeing > > > > aexp -> qvar (variable) > > | gcon (general constructor) > > ... > > | qcon { fbind1 … fbindn } (labeled construction) > > | aexp { fbind1 … fbindn } (labelled update) > > > > and > > > https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003 > > > > I realise that the update requires at least one field binding whereas > > for a construction "C {}" (n = 0) could be used. ("C {}" makes sense > > for patterns!) > > > > And due to the meta-rule a labelled update is not possible for a lambda > > abstraction, let expression, or conditional (as aexp), but it is for > > case (and do if the record type happens to be a monad). So a further > > less obvious example is: > > > > case e of > > p -> r > > { f = v } > > > > that will be parsed as: (case e of p -> r) { f = v } > > > > (I'm sure the grammar could be fully disambiguated, but this would not > > improve readability. Preferring shift over reduce is common and fine for > > such cases.) > > Upon reading this example, I believed this to be simply a matter of > the layout rule. > > case e of > p -> r > { f = v } > > would become > > case e of { > p -> r > } { f = v } > > This, on the other hand > > case e of p -> r { f = v } > > would be equivalent to > > case e of { p -> (r { f = v }) } > > I just tested this after writing the preceding as I was confused about > what you found confusing, and I am surprised that the example you > showed does indeed yield a parse error. I very much expected this to > be valid Haskell: > > data X = X { x :: Bool } > someX = X True > > foo = > case () of > _ -> someX > { x = False } > > Am I alone in my surprise? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users