ArgumentDo proposal updated

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ArgumentDo proposal updated

Akio Takano
Hi glasgow-haskell-users,

Thank you for all the feedback to the ArgumentDo proposal. Following
the discussion, I made changes to the proposal and updated the wiki
page [0].

Now the proposed grammar is greatly simplified: it doesn't add a new
non-terminal anymore, indeed it removes one instead. The proposed set
of accepted programs remains unchanged.

I hope the this update addresses one major concern that was raised in
the previous discussion.

Any feedback is appreciated.

Regards,
Takano Akio

[0]: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: ArgumentDo proposal updated

Haskell - Glasgow-haskell-users mailing list
I've added record construction and update to the syntax, which makes it clearer how the other constructs are analogous to them.

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  [hidden email]] On Behalf Of Akio Takano
|  Sent: 11 July 2016 03:24
|  To: [hidden email]
|  Subject: ArgumentDo proposal updated
|  
|  Hi glasgow-haskell-users,
|  
|  Thank you for all the feedback to the ArgumentDo proposal. Following
|  the discussion, I made changes to the proposal and updated the wiki
|  page [0].
|  
|  Now the proposed grammar is greatly simplified: it doesn't add a new
|  non-terminal anymore, indeed it removes one instead. The proposed set
|  of accepted programs remains unchanged.
|  
|  I hope the this update addresses one major concern that was raised in
|  the previous discussion.
|  
|  Any feedback is appreciated.
|  
|  Regards,
|  Takano Akio
|  
|  [0]: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  [hidden email]
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
|  users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c4ef11cd0d5d041
|  3ac28108d3a9327fd1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=flpo46
|  T9CWuGH8ndJY3roC44iubY7U8xeYWkJ2J8Img%3d
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ArgumentDo proposal updated

C Maeder-2
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.)

Cheers Christian


Am 12.07.2016 um 10:36 schrieb Simon Peyton Jones via Glasgow-haskell-users:

> I've added record construction and update to the syntax, which makes it clearer how the other constructs are analogous to them.
>
> Simon
>
> |  -----Original Message-----
> |  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> |  [hidden email]] On Behalf Of Akio Takano
> |  Sent: 11 July 2016 03:24
> |  To: [hidden email]
> |  Subject: ArgumentDo proposal updated
> |  
> |  Hi glasgow-haskell-users,
> |  
> |  Thank you for all the feedback to the ArgumentDo proposal. Following
> |  the discussion, I made changes to the proposal and updated the wiki
> |  page [0].
> |  
> |  Now the proposed grammar is greatly simplified: it doesn't add a new
> |  non-terminal anymore, indeed it removes one instead. The proposed set
> |  of accepted programs remains unchanged.
> |  
> |  I hope the this update addresses one major concern that was raised in
> |  the previous discussion.
> |  
> |  Any feedback is appreciated.
> |  
> |  Regards,
> |  Takano Akio
> |  
> |  [0]: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
> |  _______________________________________________
> |  Glasgow-haskell-users mailing list
> |  [hidden email]
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
> |  users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c4ef11cd0d5d041
> |  3ac28108d3a9327fd1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=flpo46
> |  T9CWuGH8ndJY3roC44iubY7U8xeYWkJ2J8Img%3d
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ArgumentDo proposal updated

Manuel Gómez
On Wed, Jul 13, 2016 at 5:42 AM, C Maeder <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ArgumentDo proposal updated

Brandon Allbery
On Wed, Jul 13, 2016 at 1:35 PM, Manuel Gómez <[hidden email]> wrote:
  foo =
    case () of
      _ -> someX
    { x = False }

Am I alone in my surprise?

My own expectation would be that the outdent to the level of "case" terminated the "case", and that is indeed a syntax error.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ArgumentDo proposal updated

Iavor Diatchki
In reply to this post by Manuel Gómez
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 <[hidden email]> wrote:
On Wed, Jul 13, 2016 at 5:42 AM, C Maeder <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users