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

Matthías Páll Gissurarson mpg at mpg.is
Wed Apr 2 09:26:03 UTC 2025


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> 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> 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> 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
>>>
>>> [1]
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397
>>>
>>> [2]
>>>
>>> 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>>
>>> 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>> 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
>>> >
>>> >
>>> >         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>>:
>>> >
>>> >
>>> >
>>> >             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>>
>>> 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>
>>> >              > >
>>> >              > > I’m in support.
>>> >              > >
>>> >              > > Best
>>> >              > > Malte
>>> >              > > _______________________________________________
>>> >              > > 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
>>> >
>>> >              > >
>>> >
>>> >
>>> >             --
>>> >
>>>  ----------------------------------------------------------------------
>>> >             Erik de Castro Lopo
>>> >             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>
>>> >
>>> 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
>>> >
>>> >
>>> >     _______________________________________________
>>> >     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
>>> >
>>> 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
>>> <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
>>> 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
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/20250402/13202606/attachment-0001.html>


More information about the ghc-steering-committee mailing list