ArgumentDo proposal updated

[Iavor Diatchki]

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 <targen at gmail.com> wrote:

> On Wed, Jul 13, 2016 at 5:42 AM, C Maeder <chr.maeder at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160713/93ac8cda/attachment.html>