[ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
Adam Gundry
adam at well-typed.com
Tue Apr 8 09:00:01 UTC 2025
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