<div dir="ltr">Hello Manuel,<div><br></div><div>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.</div><div><br>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.</div><div><br></div><div>Making this change would allow the kind of thing you were expecting, which to me makes sense.  Others seem to find it confusing :-)</div><div><br></div><div>-Iavor</div><div><br></div><div><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 10:35 AM, Manuel Gómez <span dir="ltr"><<a href="mailto:targen@gmail.com" target="_blank">targen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jul 13, 2016 at 5:42 AM, C Maeder <<a href="mailto:chr.maeder@web.de">chr.maeder@web.de</a>> wrote:<br>
> seeing<br>
><br>
>  aexp -> qvar                              (variable)<br>
>       |  gcon                              (general constructor)<br>
>       ...<br>
>       |  qcon { fbind1 … fbindn }          (labeled construction)<br>
>       |  aexp { fbind1 … fbindn }          (labelled update)<br>
><br>
> and<br>
> <a href="https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003" rel="noreferrer" target="_blank">https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003</a><br>
><br>
> I realise that the update requires at least one field binding whereas<br>
> for a construction "C {}" (n = 0) could be used.  ("C {}" makes sense<br>
> for patterns!)<br>
><br>
> And due to the meta-rule a labelled update is not possible for a lambda<br>
> abstraction, let expression, or conditional (as aexp), but it is for<br>
> case (and do if the record type happens to be a monad). So a further<br>
> less obvious example is:<br>
><br>
>   case e of<br>
>     p -> r<br>
>   { f = v }<br>
><br>
> that will be parsed as: (case e of p -> r) { f = v }<br>
><br>
> (I'm sure the grammar could be fully disambiguated, but this would not<br>
> improve readability. Preferring shift over reduce is common and fine for<br>
> such cases.)<br>
<br>
</span>Upon reading this example, I believed this to be simply a matter of<br>
the layout rule.<br>
<span class=""><br>
  case e of<br>
    p -> r<br>
  { f = v }<br>
<br>
</span>would become<br>
<span class=""><br>
  case e of {<br>
    p -> r<br>
  } { f = v }<br>
<br>
</span>This, on the other hand<br>
<span class=""><br>
  case e of p -> r { f = v }<br>
<br>
</span>would be equivalent to<br>
<br>
  case e of { p -> (r { f = v }) }<br>
<br>
I just tested this after writing the preceding as I was confused about<br>
what you found confusing, and I am surprised that the example you<br>
showed does indeed yield a parse error.  I very much expected this to<br>
be valid Haskell:<br>
<br>
  data X = X { x :: Bool }<br>
  someX = X True<br>
<br>
  foo =<br>
    case () of<br>
      _ -> someX<br>
    { x = False }<br>
<br>
Am I alone in my surprise?<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br>
</div></div></blockquote></div><br></div></div></div>