[ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding

Spiwack, Arnaud arnaud.spiwack at tweag.io
Thu Nov 12 08:23:44 UTC 2020


For the sake of completeness, let me note that Ocaml has a type-based
disambiguation of the sort. I've never heard anyone complain about it
(though maybe they have); however I've never knowingly depended on it
myself, so I'm not a good devil's advocate here.

On Wed, Nov 4, 2020 at 8:45 PM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> I have never used DuplicateRecordFields, but this simplification makes
> sense to me.
>
> Alejandro
>
> El mié., 4 nov. 2020 a las 19:02, Richard Eisenberg (<rae at richarde.dev>)
> escribió:
>
>> I am in favor -- I've never liked the current behavior much and will be
>> glad to see it removed.
>>
>> Richard
>>
>> On Nov 4, 2020, at 11:49 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> I have no strong opinion about this proposal, although removing code is
>> always good.
>>
>> I find the argument about pattern synonyms convincing, however. And the
>> idea of using `RecordDotSyntax` and type classes to sort type-oriented
>> disambiguation out is certainly appealing.
>>
>> So take my vote as a soft yes.
>>
>> /Arnaud
>>
>> On Wed, Nov 4, 2020 at 5:09 PM Eric Seidel <eric at seidel.io> wrote:
>>
>>> I agree that the current behavior is often unintuitive and would be
>>> better supported by RecordDotSyntax.
>>>
>>> On Wed, Nov 4, 2020, at 10:27, Simon Peyton Jones via
>>> ghc-steering-committee wrote:
>>> >
>>> > As I say on the discussion thread, I’m strongly in favour.
>>> >
>>> >
>>> > Simon
>>> >
>>> >
>>> >
>>> > *From:* ghc-steering-committee
>>> > <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Tom
>>> Harding
>>> > *Sent:* 04 November 2020 15:22
>>> > *To:* ghc-steering-committee at haskell.org
>>> > *Subject:* Re: [ghc-steering-committee] Please review #366:
>>> > DuplicateRecordFields without ambiguous field access, Shepherd: Tom
>>> > Harding
>>> >
>>> >
>>> >
>>> > Hi all,
>>> >
>>> > I’d like to open committee discussion for *DuplicateRecordFields
>>> > without ambiguous field access*. Other committee members have already
>>> > commented, and I’ll say I’m strongly in favour of this proposal. I
>>> > definitely see the suggestion here as “tidying up” an unintuitive -
>>> > perhaps even counterintuitive - behaviour.
>>> >
>>> >
>>> >
>>> > https://github.com/ghc-proposals/ghc-proposals/pull/366
>>> > <
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F366&data=04%7C01%7Csimonpj%40microsoft.com%7C943716dad34746aa01dd08d880d57d9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401003095757046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8T%2FxKBAkwtJgmCeg0%2BIr8IuOURniTXvGd%2F7%2FbIgbcGg%3D&reserved=0>
>>>
>>> >
>>> >
>>> >
>>> > Thanks,
>>> >
>>> > Tom
>>> >
>>> >
>>> > PS. Sorry for my recent absence; I think it has been a very strange
>>> few
>>> > months for all us!
>>> >
>>> >
>>> >
>>> > > On 2 Nov 2020, at 09:08, Joachim Breitner <mail at joachim-breitner.de>
>>> wrote:
>>> > >
>>> > > Dear Committee,
>>> > >
>>> > > this is your secretary speaking:
>>> > >
>>> > > DuplicateRecordFields without ambiguous field access
>>> > > was proposed by Adam Gundry
>>> > > https://github.com/ghc-proposals/ghc-proposals/pull/366 <
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F366&data=04%7C01%7Csimonpj%40microsoft.com%7C943716dad34746aa01dd08d880d57d9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401003095767043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=O7yXaTttgOLAEC36SQF%2FK9INxrBxiUazko6iEDZOMqo%3D&reserved=0
>>> >
>>> > >
>>> https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst
>>> > >
>>> > > I’ll propose Tom Harding as the shepherd.
>>> > >
>>> > > Please guide us to a conclusion as outlined in
>>> > > https://github.com/ghc-proposals/ghc-proposals#committee-process
>>> > >
>>> > > Thanks,
>>> > > Joachim
>>> > > --
>>> > > Joachim Breitner
>>> > >  mail at joachim-breitner.de
>>> > >  http://www.joachim-breitner.de/
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > 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
>>> >
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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/20201112/84d14daa/attachment.html>


More information about the ghc-steering-committee mailing list