[ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
Adam Gundry
adam at well-typed.com
Tue May 6 12:38:17 UTC 2025
Hi everyone,
After a few rounds of editing to improve the spec, Simon has declared
himself satisfied with #668. It now generalises OverloadedRecordDot and
OverloadedRecordUpdate to support arbitrary field labels (consistent
with OverloadedLabels) and does some general tidying up of the spec:
https://github.com/ghc-proposals/ghc-proposals/pull/668
https://github.com/parsonsmatt/ghc-proposals/blob/patch-1/proposals/0282-record-dot-syntax.rst
I believe there were no other concerns, so unless anyone objects I plan
to declare this accepted in a week or so.
Cheers,
Adam
On 08/04/2025 10:00, Adam Gundry via ghc-steering-committee 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
More information about the ghc-steering-committee
mailing list