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

Adam Gundry adam at well-typed.com
Mon Apr 7 15:21:10 UTC 2025


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