[ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
Arnaud Spiwack
arnaud.spiwack at tweag.io
Wed Apr 2 05:56:04 UTC 2025
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
>>
>> _______________________________________________
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250402/154bb3fc/attachment.html>
More information about the ghc-steering-committee
mailing list