[ghc-steering-committee] Record syntax

Tue Jan 28 11:24:01 UTC 2020

I abstain, as I don't have a strong enough opinion to vote. Happy to have others decide.

Richard

> On Jan 28, 2020, at 11:07 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> Friends
> 
> Sorry for dragging my feet here.   
> 
> Only Joachim, Arnaud, Simon, and Eric responded to my message below.   If that means that the rest of you don’t mind either way, that’s fine. But if you have an opinion, please say so in the next 24 hrs.
> 
> No one seems keen on (1).
> 
> Everyone seems on the fence between (2) and (3).
> 
> Personally I prefer (2) over (3).  I’m very uncomfortable about an infix white-space operator that binds more tightly than function application.  Consider  (f .x g .y h .z)
> 
> (2) says this means ((((f .x) g) .y) h) .z), so that it parenthesises exactly like function application.
> (3) says it means (((f .x) (g .y)) (h .z)) which, while unambiguous, I dislike cordially.
> I propose to adopt (2).  We can vote if need be, but I’d like to hear from anyone who thinks that’s a wrong choice.  Clearly it’s a judgement call.
> 
> Simon
> 
>  
> 
> From: Simon Peyton Jones <simonpj at microsoft.com> 
> Sent: 07 January 2020 11:29
> To: ghc-steering-committee at haskell.org
> Cc: Simon Peyton Jones <simonpj at microsoft.com>
> Subject: Record syntax
>  
> 
> Friends
> 
> I’d like to move our record-syntax discussion forward.  Link to proposal discussion <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7Ca982a7a9c68f4a7b4a3808d79364cd25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139933453096241&sdata=ITgdpzLSfuPL9ZlqoPt6NQpiPNlXcJGRIkgBLkRD4hE%3D&reserved=0>, and December GHC steering committee debates <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-December%2Fthread.html%231387&data=02%7C01%7Csimonpj%40microsoft.com%7Ca982a7a9c68f4a7b4a3808d79364cd25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139933453106239&sdata=okRmErY9Rw0Y2tY4pPXPyuZtOCwj%2FG8BMqz9sxPtNOA%3D&reserved=0>.
> 
> No-space arguments
> I believe have agreed that 
> 
>                f r.x
> 
> (with no spaces around the dot, and no parens around r.x) means
> 
>                f (r.x)
> 
> That is, treat it consistently with qualified names.  I asked everyone to express a view; Iavor, Eric, Arnaud, Joachim, and Richard all said it was at least acceptable; others expressed no view.  So let’s take that as a decision, at least for now.
> 
> Naked selectors
> Next question: how should we treat a “naked selector”, namely .x where there is no space after the dot, but there is a space before.  I think there are three viable choices:
> 
> It’s simply illegal.   This defers the choice;  perhaps later we will have more experience to go on.
> It’s a postfix operator, binding less tightly than function application, but more tightly than any infix operator.   So then (r .x) means r.x, and (r .x .y) means r.x.y.   But (f r .x) means (f r).x.
> This choice naturally supports chaining (nice to have, but not essential).  We can write
> 
> f .map double
>   .filter isEven
> meaning (f.map double).filter isEven
> 
> It’s a postfix operator, binding more tightly than function application, just as record update does.  So then (f r .x) means (f r.x), and (f r .x .y s .z) means (f r.x.y s.z).
> This choice allows us to regard our decision about (f r.x) as what naturally happens if we parse it as three lexemes: f, r, and .x.  But it also breaks the “function application binds more tightly than anything else” rule, just as (f r {x=3}) sadly does already.
> 
> It does not permit chaining, at least not without stacked-up parens.
> 
> In all three cases we allow (.x), meaning (\r. r.x).   For (2) and (3) we can regard it as a “section”, like infix operators only simpler because there is no argument.
> 
> I think this is the last major question we have to answer.
> 
> What are your views?   Personally I lean towards (2), but I could certainly live with (1).  I’m a bit reluctant to adopt (3).
> 
> Simon
> 
>  
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200128/6279b2f6/attachment-0001.html>