Re: [ghc-steering-committee] RecordDotSyntax: please express a view

10 Dec 2019

      |  To be concrete, I propose this:

Not concrete enough.  I don't understand 

|  prefix             with a ( before the .: field selector
|                     otherwise: field access

What does (f a .b c .d e) mean?

You may be arguing that naked `.x` is a *postfix operator*, rather like factorial when we write 5!.   If so, it should have a precedence etc, and presumably binds less tightly than function application.  So
	f a .b c .d e
would presumably mean
	((f a).b c).d e

That might be OK.  I don’t recall the discussion articulating it like this, but it seems defensible.

Simon

|  -----Original Message-----
|  From: Richard Eisenberg <rae@richarde.dev>
|  Sent: 10 December 2019 14:17
|  To: Simon Peyton Jones <simonpj@microsoft.com>
|  Cc: Joachim Breitner <mail@joachim-breitner.de>; ghc-steering-
|  committee@haskell.org
|  Subject: Re: [ghc-steering-committee] RecordDotSyntax: please express
|  a view
|  
|  I'm in support of this proposal.
|  
|  I don't think it's fantastic. (In particular, I'm bothered about the
|  lack of polymorphic update.) But it seems willfully disdainful of our
|  users if we don't do *something*. This is the closest we've gotten to
|  a solution here. Let's not turn down now. And perhaps with
|  impredicativity, new doors will open up in the future.
|  
|  As to the Great Whitespace Debate: I prefer requiring the parens for
|  the selector section: (.foo). It makes this more like other sections.
|  A related question (that seems unconsidered by the proposal) is: if we
|  require parens for the section, what does a bare `.foo` mean? If we
|  don't allow
|  
|  >  x.foo
|  >   .bar
|  >   .baz
|  
|  then what do users do if they have long field names? Are we reduced to
|  writing
|  
|  >  (x.foo.bar
|  >     ).baz
|  
|  ? That's awful. I remember this coming up in the commentary, but I'm
|  not quite sure how to search for it.
|  
|  To be concrete, I propose this:
|  
|  Position of .      Meaning
|  --------           -------
|  tight infix        with a conid before the .: module qualification
|                     with anything else before the .: field access
|  suffix             parse error
|  prefix             with a ( before the .: field selector
|                     otherwise: field access
|  loose infix        normal, user-definable operator (defined to be
|  composition in the Prelude)
|  
|  Note that the lexer must tag the . with its position, and then parsing
|  is easy to implement. Effectively, a prefix . slurps up all the
|  preceding whitespace. No weird precedence rules necessary.
|  
|  To be clear: I don't feel very strongly on this point, and I support
|  the proposal with any discussed conclusion to the Great Whitespace
|  Debate. Yet, as a committee member, I make my vote as I have written
|  here.
|  
|  Richard
|  
|  
|  > On Dec 10, 2019, at 12:47 PM, Simon Peyton Jones via ghc-steering-
|  committee <ghc-steering-committee@haskell.org> wrote:
|  >
|  > |  About the contentious issue of (.foo) vs. .foo, I am squarely in
|  the
|  > |  (.foo) camp,
|  >
|  > Although I recommended allowing naked .foo, if there is a consensus
|  on the committee for (.foo), with a naked .foo being illegal, then I'm
|  quite willing to support that position too.   After all, it just makes
|  more programs illegal, we can always allow naked .foo later.
|  >
|  > I don't think anyone is proposing that
|  > 	f g .x h .y z
|  > means
|  > 	f (g.x) (h.y) z
|  > I would cordially dislike that, as I do the current record update
|  syntax precedence rules.
|  >
|  > Simon
|  >
|  > |  -----Original Message-----
|  > |  From: ghc-steering-committee <ghc-steering-committee-
|  > |  bounces@haskell.org> On Behalf Of Joachim Breitner
|  > |  Sent: 10 December 2019 11:41
|  > |  To: ghc-steering-committee@haskell.org
|  > |  Subject: Re: [ghc-steering-committee] RecordDotSyntax: please
|  express
|  > |  a view
|  > |
|  > |  Hi,
|  > |
|  > |  TL;DR: Support acceptance, preference for (.foo) over .foo.
|  > |
|  > |  I guess many people are excited, so overall good to get this.
|  > |
|  > |  I recently stopped using Haskell for something where readability
|  was
|  > |  the primary goal for lack of nested access and updates. So yay!
|  :-)
|  > |
|  > |  I am a bit unhappy about the “Higher-rank fields” problem. Not
|  that I
|  > |  use such field often, but it came up in the “Overloaded do”
|  proposal.
|  > |  Maybe accepting this will increase the chances of a getField
|  variant
|  > |  that works even in impredicative cases.
|  > |
|  > |  I hope pattern matching will follow, but no need to have it in
|  this
|  > |  proposal.
|  > |
|  > |
|  > |  About the contentious issue of (.foo) vs. .foo, I am squarely in
|  the
|  > |  (.foo) camp, for all the gut-feeling reasons given elsewhere in
|  > |  abundance. My main reasons: feels like a syntactic section to me,
|  and
|  > |  less danger of wat effects for people coming from languages with
|  the
|  > |
|  > |    a.foo
|  > |     .bar
|  > |     .baz
|  > |
|  > |  idiom…
|  > |
|  > |
|  > |  I will not veto the current form, but Eric may be in less of a
|  > |  minority
|  > |  that he thinks.
|  > |
|  > |
|  > |
|  > |  The precedence rule
|  > |
|  > |     f a.b.c 10
|  > |
|  > |  being
|  > |
|  > |     f (a.b.c) 10
|  > |
|  > |  makes sense when one comes from Ocaml or similar languages, or
|  has
|  > |  thought about record updates for a long time. There is a trace of
|  a
|  > |  feeling that this is un-Haskellish in the same way as
|  > |
|  > |     f a { b = c } 10
|  > |
|  > |  is. But at least we don't allow spaces around the dot, so it is
|  > |  probably fine.
|  > |
|  > |
|  > |  Cheers,
|  > |  Joachim
|  > |
|  > |
|  > |
|  > |
|  > |
|  > |
|  > |  Am Montag, den 09.12.2019, 22:57 +0000 schrieb Simon Peyton Jones
|  via
|  > |  ghc-steering-committee:
|  > |  > Dear steering committee
|  > |  >
|  > |  > I'm the shepherd for the RecordDotSyntax proposal.
|  > |  >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fghc-proposals%2Fghc-
|  > |
|  proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C84
|  > |
|  3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  > |
|  7C0%7C637115748567847774&sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
|  > |  stuHOeq0%3D&reserved=0
|  > |  >
|  > |  > I recommend acceptance:
|  > |  >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F282%23issuecomment-
|  > |
|  563477691&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  > |
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  > |
|  48567847774&sdata=9bwoFCaNRGH62hV7LvKvCPbiFXYQjAaSPgUKe6ttLtw%3D&a
|  > |  mp;reserved=0
|  > |  >
|  > |  > Please reads the proposal, and as much of the discussion as you
|  feel
|  > |  able, and respond in the next week or two to indicate your views.
|  > |  >
|  > |  > Remember: ask technical questions on the Github discussion
|  thread,
|  > |  and use this mailing list for more evaluative discussion of
|  judgement
|  > |  or opinion.
|  > |  >
|  > |  > I'd love every member of the committee to express a view.  This
|  > |  proposal has attracted a lot of interest.
|  > |  >
|  > |  > Thanks
|  > |  >
|  > |  > Simon
|  > |  >
|  > |  > > -----Original Message-----
|  > |  > > From: ghc-steering-committee <ghc-steering-committee-
|  > |  bounces@haskell.org>
|  > |  > > On Behalf Of Joachim Breitner
|  > |  > > Sent: 28 November 2019 10:11
|  > |  > > To: ghc-steering-committee@haskell.org
|  > |  > > Subject: [EXTERNAL] [ghc-steering-committee] Please review
|  #282:
|  > |  > > RecordDotSyntax, Shepherd: Simon PJ
|  > |  > >
|  > |  > > Dear Committee,
|  > |  > >
|  > |  > > this is your secretary speaking:
|  > |  > >
|  > |  > > RecordDotSyntax language extension proposal has been proposed
|  by
|  > |  Neil
|  > |  > > Mitchell and Shayne Fletcher
|  > |  > >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fghc-proposals%2Fghc-
|  > |
|  proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C84
|  > |
|  3ae99c854745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  > |
|  7C0%7C637115748567847774&sdata=gcW6OmpCccSbVaC5AmkFdJtrpwbdo1EIEy7
|  > |  stuHOeq0%3D&reserved=0
|  > |  > >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-
|  > |
|  &data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9a3f08d7
|  > |
|  7d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157485678477
|  > |
|  74&sdata=Kno9%2Fitm3REWI6roXdLQ88tSpDA%2FeJvY8bb4XKKJI1g%3D&re
|  > |  served=0
|  > |  > > syntax/proposals/0000-record-dot-syntax.md
|  > |  > >
|  > |  > > This is going to be a tricky one. It is partly about
|  whitespace,
|  > |  so it
|  > |  > > has attracted a _lot_ of community interest, by far the most
|  so
|  > |  far. To
|  > |  > > navigate that ship, I propose Simon PJ as the shepherd,
|  because he
|  > |  is a
|  > |  > > excellent moderator and community manager, and because he has
|  the
|  > |  > > necessary authority to hopefully get a verdict accepted.
|  > |  > >
|  > |  > > Please reach consensus as described in
|  > |  > >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > |  ub.com%2Fghc-proposals%2Fghc-proposals%23committee-
|  > |
|  process&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745dc9
|  > |
|  a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115748
|  > |
|  567847774&sdata=0eXaTaxw81Z2szF2KGZ3qxbJgSgx3wQZUii8rr1XytM%3D&
|  > |  ;reserved=0
|  > |  > > I suggest you make a recommendation, in a new e-mail thread
|  with
|  > |  the
|  > |  > > proposal number in the subject, about the decision, maybe
|  point
|  > |  out
|  > |  > > debatable points, and assume that anyone who stays quiet
|  agrees
|  > |  with you.
|  > |  > >
|  > |  > > Thanks,
|  > |  > > Joachim
|  > |  > > --
|  > |  > > Joachim Breitner
|  > |  > >   mail@joachim-breitner.de
|  > |  > >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  > |  oachim-
|  > |
|  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
|  > |
|  4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  > |
|  7115748567847774&sdata=aeTui1sCsvRGKFzUnyZHzKL%2FwBF0NLDGR%2BmJ5yT
|  > |  UfrE%3D&reserved=0
|  > |  > >
|  > |  > > _______________________________________________
|  > |  > > ghc-steering-committee mailing list
|  > |  > > ghc-steering-committee@haskell.org
|  > |  > >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  > |
|  committee&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  > |
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  > |
|  48567847774&sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%3D
|  > |  &reserved=0
|  > |  > _______________________________________________
|  > |  > ghc-steering-committee mailing list
|  > |  > ghc-steering-committee@haskell.org
|  > |  >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  > |
|  committee&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  > |
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  > |
|  48567847774&sdata=hpyFheQhmtsGFHpKDn1US%2FIwi8OmgWdpk1IdT5v3YDo%3D
|  > |  &reserved=0
|  > |  --
|  > |  Joachim Breitner
|  > |    mail@joachim-breitner.de
|  > |
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  > |  oachim-
|  > |
|  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c85
|  > |
|  4745dc9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  > |
|  7115748567857762&sdata=id%2Bw%2FzvZX%2FbgV%2FBovQ85ByF7KFdkU8NKtxU
|  > |  eygGeYKU%3D&reserved=0
|  > |
|  > |  _______________________________________________
|  > |  ghc-steering-committee mailing list
|  > |  ghc-steering-committee@haskell.org
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  > |
|  committee&data=02%7C01%7Csimonpj%40microsoft.com%7C843ae99c854745d
|  > |
|  c9a3f08d77d65d0d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371157
|  > |
|  48567857762&sdata=zUhQrs20IkgPfD4lBZIxTYQSBFVlIOP7itXhTTLut6A%3D&a
|  > |  mp;reserved=0
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee@haskell.org
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4905b1dc7a4474
|  4c43b08d77d7b9d5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371158
|  42192614669&sdata=Xh0SopxeypTlM%2B31iuHJNQMRzNt2sTLGXbdmYjGu3CQ%3D
|  &reserved=0