[ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept

Simon Peyton Jones simon.peytonjones at gmail.com
Wed Apr 9 09:02:17 UTC 2025


I'm thumbs up -- but I have added a post with a list of suggested
presentational cleanups.

(Adam if you are worn out I suppose I could execute on them myself.  I
don't want to keep erecting new obstacles.)

Simon

On Wed, 9 Apr 2025 at 03:31, Jakob Brünker via ghc-steering-committee <
ghc-steering-committee at haskell.org> wrote:

> Hi,
>
> The updated proposal looks good to me!
>
> Jakob
>
> On Tue, Apr 8, 2025 at 11:00 AM Adam Gundry via ghc-steering-committee <
> ghc-steering-committee at haskell.org> wrote:
>
>> I have now updated this proposal on the basis of the vote:
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/668
>>
>> Please take a look and let me know if you are happy with the current
>> state of the PR, or have any remaining concerns.
>>
>> Thanks,
>>
>> Adam
>>
>> P.S. I will be away on holiday over the next couple of weeks, so
>> apologies in advance for any delays in response.
>>
>>
>> On 07/04/2025 16:21, Adam Gundry via ghc-steering-committee wrote:
>> > Thanks everyone for your responses to this. There seems to be a fairly
>> > clear consensus that the preferred option is B. (5 votes have B in
>> first
>> > place, then 3 others either rate A and B equally or weakly prefer A to
>> > B.) Thus I plan to revise the proposal accordingly.
>> >
>> > Adam
>> >
>> >
>> >
>> > On 02/04/2025 10:26, Matthías Páll Gissurarson via
>> > ghc-steering-committee wrote:
>> >> I have a slight preference for B over A. The point that [2] brings up
>> >> is a good one, it seems better to allow row.“foo bar”, especially when
>> >> reading CSV or JSON as they mention.
>> >>
>> >> So my preference is B>A>C>D
>> >>
>> >> /Matti Palli
>> >>
>> >>
>> >> On Wed, Apr 2, 2025 at 07:56 Arnaud Spiwack via ghc-steering-committee
>> >> <ghc-steering-committee at haskell.org
>> >> <mailto:ghc-steering-committee at haskell.org>> wrote:
>> >>
>> >>     My preference is
>> >>     A>B>C>D
>> >>
>> >>     Though my preference between A and B is weak. Whatever's easier
>> >> really.
>> >>
>> >>     On Thu, 20 Mar 2025 at 19:04, Simon Marlow via
>> >>     ghc-steering-committee <ghc-steering-committee at haskell.org
>> >>     <mailto:ghc-steering-committee at haskell.org>> wrote:
>> >>
>> >>         I don't feel all that strongly except that C seems like a bad
>> >>         idea. A = B > D > C
>> >>
>> >>         Cheers
>> >>         Simon
>> >>
>> >>         On Wed, 19 Mar 2025 at 21:49, Adam Gundry via
>> >>         ghc-steering-committee <ghc-steering-committee at haskell.org
>> >>         <mailto:ghc-steering-committee at haskell.org>> wrote:
>> >>
>> >>             Hi everyone,
>> >>
>> >>             This proposal [0] has been lingering for quite some time,
>> >>             unfortunately.
>> >>             So we can make progress, I've tried to summarise our
>> options
>> >>             below;
>> >>             please vote for your preferred option in the next week or
>> >>             two.  Once we
>> >>             have decided on our preferred course of action, I'll make
>> >>             any necessary
>> >>             editorial changes to the proposal.
>> >>
>> >>             To recap, the idea is to extend OverloadedRecordDot such
>> >>             that it permits
>> >>             record selection expressions such as
>> >>
>> >>                  foo.type   ->   getField @"type" foo
>> >>
>> >>             even though `type` is a keyword and hence not a valid
>> record
>> >>             field in a
>> >>             traditional datatype declarations. This is primarily
>> >>             motivated by the
>> >>             use of OverloadedRecordDot in libraries such as
>> `persistent`
>> >>             (see [1]),
>> >>             which will generate instances like this:
>> >>
>> >>                  instance HasField "type" SomeRecord SomeField1 where
>> >>                    getField = ...
>> >>
>> >>                  instance HasField "bar" SomeRecord SomeField2 where
>> >>                    getField = ...
>> >>
>> >>             Both these instances are accepted, so it is quite
>> surprising
>> >>             and
>> >>             annoying that `foo.type` is a syntax error, even though
>> >>             `foo.bar` will
>> >>             be accepted (and turn into a call to `getField @"bar"`).
>> >>
>> >>             As a small syntactic change, the proposal has lead to quite
>> >>             some
>> >>             discussion and a few plausible alternatives:
>> >>
>> >>                A. Accept the proposal as it stands, since it is the
>> >>             smallest change
>> >>             that resolves the issue.
>> >>
>> >>                B. Extend the proposal to permit still wider syntax,
>> e.g.
>> >>             `foo.Uppercase` or `foo."quoted string"`, motivated by
>> >>             consistency with
>> >>             OverloadedLabels and use cases such as [2]. This seems
>> >>             reasonable to me.
>> >>
>> >>                C. Extend the proposal to permit keywords such as `type`
>> >>             to be used as
>> >>             field names in traditional record syntax, e.g. `data Foo =
>> >>             Foo { type ::
>> >>             Int }`. In my view this is unnecessary complexity that
>> >>             mistakenly
>> >>             conflates OverloadedRecordDot with traditional record
>> >>             syntax; the
>> >>             motivation for keywords as selector names comes from uses
>> of
>> >>             OverloadedRecordDot that do not involve traditional record
>> >>             syntax.
>> >>
>> >>                D. Reject the proposal entirely, e.g. due to worries
>> >>             about syntax
>> >>             highlighting.
>> >>
>> >>             Please reply with your preference order amongst these
>> >>             options. My vote
>> >>             is B > A > C > D.
>> >>
>> >>             Thanks,
>> >>
>> >>             Adam
>> >>
>> >>
>> >>             [0]
>> https://github.com/ghc-proposals/ghc-proposals/pull/668
>> >>             <https://github.com/ghc-proposals/ghc-proposals/pull/668>
>> >>
>> >>             [1]
>> >>
>> >>
>> https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397
>> <
>> https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397
>> >
>> >>
>> >>             [2]
>> >>
>> >>
>> https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901
>> <
>> https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901
>> >
>> >>
>> >>
>> >>
>> >>             On 05/11/2024 13:58, Arnaud Spiwack wrote:
>> >>              > I have no opinion on this. But I've seen two points in
>> >>             the thread which
>> >>              > make sense: Vlad, our guardian of the parser, says that
>> >>             it's a good
>> >>              > idea, and the comparison with OverloadedLabel (made by
>> >>             Vlad and others)
>> >>              > is apt, and the symmetry is desirable. Ideally the
>> >>             comparison with
>> >>              > OverloadedLabel should be made in the Alternatives
>> >>             section, but I don't
>> >>              > feel like insisting about it :) .
>> >>              >
>> >>              > On Sat, 2 Nov 2024 at 21:21, Simon Peyton Jones
>> >>              > <simon.peytonjones at gmail.com
>> >>             <mailto:simon.peytonjones at gmail.com>
>> >>             <mailto:simon.peytonjones at gmail.com
>> >>             <mailto:simon.peytonjones at gmail.com>>> wrote:
>> >>              >
>> >>              >     I'm in support too, but I have made some substantive
>> >>             suggestions on
>> >>              >     the GitHub ticket that I'd like to see addressed
>> >>             before we tie a bow
>> >>              >     on this.
>> >>              >
>> >>              >     Simon
>> >>              >
>> >>              >     On Sat, 2 Nov 2024 at 09:25, Sebastian Graf
>> >>             <sgraf1337 at gmail.com <mailto:sgraf1337 at gmail.com>
>> >>              >     <mailto:sgraf1337 at gmail.com
>> >>             <mailto:sgraf1337 at gmail.com>>> wrote:
>> >>              >
>> >>              >         I'm in support as well, but would like to see a
>> >>             single
>> >>              >         clarifying sentence added to the proposal.
>> >>              >
>> >>
>> >>
>> https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003
>> <
>> https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003>
>> <
>> https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003
>> <
>> https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003
>> >>
>> >>              >
>> >>              >         Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik
>> de
>> >>             Castro Lopo
>> >>              >         <erikd at mega-nerd.com <mailto:
>> erikd at mega-nerd.com>
>> >>             <mailto:erikd at mega-nerd.com <mailto:erikd at mega-nerd.com
>> >>>:
>> >>              >
>> >>              >
>> >>              >
>> >>              >             I am in support.
>> >>              >
>> >>              >             Erik
>> >>              >
>> >>              >             Matthías Páll Gissurarson wrote:
>> >>              >
>> >>              >              > I’m in support. No need to keep
>> >>             reservations longer than
>> >>              >             necessary.
>> >>              >              >
>> >>              >              > /Matti Palli
>> >>              >              >
>> >>              >              >
>> >>              >              > On Fri, Nov 1, 2024 at 23:22 Malte Ott
>> >>              >             <malte.ott at maralorn.de
>> >>             <mailto:malte.ott at maralorn.de> <mailto:
>> malte.ott at maralorn.de
>> >>             <mailto:malte.ott at maralorn.de>>> wrote:
>> >>              >              >
>> >>              >              > >
>> >>              >              > > On 2024-10-29 20:12, Adam Gundry wrote:
>> >>              >              > > >
>> >>              > https://github.com/ghc-proposals/ghc-proposals/pull/668
>> >>             <https://github.com/ghc-proposals/ghc-proposals/pull/668>
>> >>              >
>> >>  <https://github.com/ghc-proposals/ghc-proposals/pull/668
>> >>             <https://github.com/ghc-proposals/ghc-proposals/pull/668>>
>> >>              >              > >
>> >>              >              > > I’m in support.
>> >>              >              > >
>> >>              >              > > Best
>> >>              >              > > Malte
>> >>              >              > >
>> >>             _______________________________________________
>> >>              >              > > ghc-steering-committee mailing list
>> >>              >              > > ghc-steering-committee at haskell.org
>> >>             <mailto:ghc-steering-committee at haskell.org>
>> >>              >             <mailto: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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >>
>> >>              >              > >
>> >>              >
>> >>              >
>> >>              >             --
>> >>              >
>> >>  ----------------------------------------------------------------------
>> >>              >             Erik de Castro Lopo
>> >>              > http://www.mega-nerd.com/ <http://www.mega-nerd.com/>
>> >>             <http://www.mega-nerd.com/ <http://www.mega-nerd.com/>>
>> >>              >
>> >>  _______________________________________________
>> >>              >             ghc-steering-committee mailing list
>> >>              > ghc-steering-committee at haskell.org
>> >>             <mailto:ghc-steering-committee at haskell.org>
>> >>              >             <mailto: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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >>
>> >>              >
>> >>              >         _______________________________________________
>> >>              >         ghc-steering-committee mailing list
>> >>              > ghc-steering-committee at haskell.org
>> >>             <mailto:ghc-steering-committee at haskell.org>
>> >>              >         <mailto: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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >>
>> >>              >
>> >>              >     _______________________________________________
>> >>              >     ghc-steering-committee mailing list
>> >>              > ghc-steering-committee at haskell.org
>> >>             <mailto:ghc-steering-committee at haskell.org>
>> >>              >     <mailto: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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >>
>> >>              >
>> >>              >
>> >>              >
>> >>              > --
>> >>              > Arnaud Spiwack
>> >>              > Director, Research at https://moduscreate.com
>> >>             <https://moduscreate.com> <https://moduscreate.com
>> >>             <https://moduscreate.com>>
>> >>              > and https://tweag.io <https://tweag.io> <
>> https://tweag.io
>> >>             <https://tweag.io>>.
>> >>              >
>> >>              > _______________________________________________
>> >>              > 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> >>
>> >>             --             Adam Gundry, Haskell Consultant
>> >>             Well-Typed LLP, https://www.well-typed.com/
>> >>             <https://www.well-typed.com/>
>> >>
>> >>             Registered in England & Wales, OC335890
>> >>             27 Old Gloucester Street, London WC1N 3AX, England
>> >>
>> >> <
>> https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g
>> >
>> >>
>> >>             _______________________________________________
>> >>             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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> >>
>> >>         _______________________________________________
>> >>         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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> >>
>> >>
>> >>
>> >>     --     Arnaud Spiwack
>> >>     Director, Research at https://moduscreate.com
>> >>     <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
>> >>     _______________________________________________
>> >>     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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> >>
>> >>
>> >> _______________________________________________
>> >> ghc-steering-committee mailing list
>> >> ghc-steering-committee at haskell.org
>> >>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20250409/b28b8ae7/attachment-0001.html>


More information about the ghc-steering-committee mailing list