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

[Iavor Diatchki]

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> wrote:

>
>
> On Mar 31, 2020, at 2:09 PM, Simon Peyton Jones <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
> 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/20200331/33cfbff9/attachment.html>