[ghc-steering-committee] Modification to record dot syntax propsal

[Spiwack, Arnaud]

Simon, all,

After reading more of the PR thread (in particular the fews posts after
Simon's recommendation), I have to admit: I am thoroughly confused. I'm not
sure that two people in that thread have the same motivation, end goal, or
design in mind.

The motivations provided by the modified *Alternatives* section is not much
more helpful (at the risk of caricaturing a little, it basically reads: “we
made two extensions rather than one because we can”). Though it makes it
clear that the end goal is to fold a bunch of record-related extensions
into one glorious record extension (well, probably not fold them, but make
a meta-extension that implies all the extensions that we've decided we
like).

My starting point is that:
- Additional extensions have a maintenance cost
- Additional extensions impose a cognitive burden on their use
- I expect that a new extension will break my code in the next few releases.

Based on this, I don't care how this extension or the glorious record
extension are named; but if we want to have two extensions we should have a
serious reason. Right now, the one reason that I see (and Iavor raised), is
that the update part of `RecordDotSyntax` is not backward compatible. Is it
a strong enough reason? I don't know. The only data point that I can
provide is that when we discussed the original proposal, I brought it up
several times, and it didn't seem very important at the time (the
conversation focused on other points of the proposal).

So, I'm still reluctant. I feel that, at the very least, the motivations
are not well-enough articulated in the proposal (I'll make a comment to
this effect on Github when I'm done composing this email).

I appreciate that I'm in the minority here. Yet, I'm still unconvinced.

Best,
Arnaud

On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Generally, I'm not in favour in proposals which split extensions though:
> we already have so many extensions. Are the reasons for this split strong
> enough? I haven't had time to dig into the details.
>
> Arnaud, happily, you don’t have to dig very deep – just read the handful
> of posts following my recommendation.
>
>
>
> There seem to be two motivations.
>
>
>
>    1. There really are two orthogonal extensions, one for r.x notation,
>    and one for overloaded update.  Iavor likes the first but not the second.
>    Neil likes both.  Having separate extensions lets us experiment.
>
>
>
>    1. You suggest that changing the definition of RecordDotSyntax in a
>    subsequent release, e.g. by subsequently making it imply NoFieldSelectors,
>    would be fine. But it certainly imposes pain – some programs would stop
>    compiling.  The approach offered by this proposal avoids that problem.
>
>
>
> Yes, there are lots of extensions surrounding records: NoFieldSelectors,
> DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields,
> RecordWildCards.  It may not be pretty to divide things up so fine, but
> it’s not new.
>
>
>
>
>
> If there are alternative suggestions, let’s hear them.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Spiwack, Arnaud
> *Sent:* 26 February 2021 22:33
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Modification to record dot syntax
> propsal
>
>
>
>
>
> I do think that  reusing the record update syntax for the overloaded
> monomorphic update is a mistake---it is not something I had noticed during
> our original discussion.
>
>
>
> This is the one reason I can see for cutting this extension in smaller
> pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like
> extension.
>
>
>
> Generally, I'm not in favour in proposals which split extensions though:
> we already have so many extensions. Are the reasons for this split strong
> enough? I haven't had time to dig into the details.
>
>
>
> I'm not sure that not having the design of the proposal quite finalised is
> a good reason, extensions mutate in their first iterations, I don't think
> that it's a problem.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210301/c95745b7/attachment-0001.html>