[ghc-steering-committee] Record dot syntax: vote results

[Simon Peyton Jones]

I think accepting (C2a) over (C4) is a mistake, and reading Simon's specification of (C2a) does nothing to dispel my uneasiness about this choice.
I know!  For my part, I would much prefer (C6), which also avoids this entire question, and also allows white space in selectors.  But I failed to persuade you all to vote for (C6), and I accept the result.  I suppose the same is true for you.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 31 March 2020 23:09
To: Richard Eisenberg <rae at richarde.dev>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Neil Mitchell <ndmitchell at gmail.com>; Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee <ghc-steering-committee at haskell.org>; Shayne Fletcher <shayne.fletcher at daml.com>
Subject: Re: [ghc-steering-committee] Record dot syntax: vote results

Hello,

I think accepting (C2a) over (C4) is a mistake, and reading Simon's specification of (C2a) does nothing to dispel my uneasiness about this choice.

To Alejandro's points:

   - As Joachim pointed out, (C4) is how OCaml works, not (C2a).  I wonder what the additional complexity of the specification buys us?   In the draft document Simon describes it as "more conservative", but it actually requires more work to both implement and specify.

   - Indeed, you could write some expressions that might look confusing at first, but I don't see why would you?  After all, one could use the exact same argument for many other notations in pretty much any programming language (e.g., operator precedences can be used to write confusing code---it doesn't mean that they are not very useful sometime).

   - Using white space in selectors is probably not going to be used a lot, but I could imagine it being useful if you have some nested records, and the field names are long.  For example, I could see myself writing something like this:
```
someRecord
   .outterField
   .innerField
```
I realize this style could be a matter of taste, but I don't see any reason for us to go out of our way to disallow it.

-Iavor


On Tue, Mar 31, 2020 at 7:21 AM Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:



On Mar 31, 2020, at 2:09 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

Yes I do.  Please do!   And, it’s terribly late in the day, but if anyone wants to raise a new issue, please do so.

Done. Tiny changes, but I think they will avoid the mistakes I made in interpretation.




I do wonder about explicitly calling out the possibility of having (a) the syntactic sugar of this proposal with (b) no overloading.   So that
    r.x   desugars to   (x r)
    e { x = e2 }    desugars to   case e of K { .. } -> K { x=e2, .. }
or something like that.  That is strictly beyond what the proposal currently does, which is to *always* use setField/getField.  But that means that for records with polymorphic fields you simply can’t use the proposal at all.

That is interesting, but I say that it is too late. Effectively, we've accepted this proposal (modulo "what happens next"). You're welcome to write a fresh proposal with that idea. :)

Richard
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<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%7C44c517023b9740493fe808d7d5c01c13%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212893383978680&sdata=c5WpN3xqms504KLZntXkcOEXSU7N%2BBBYZY64cKgRz0I%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200331/65bd41ca/attachment-0001.html>