[ghc-steering-committee] #583: HasField redesign, rec: accept

[Chris Dornan]

+1 from me

On Thu, 21 Sep 2023 at 08:37, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all.
>
> I submitted my recommendation 3 weeks ago, and only Simon has commented
> yet. Please let me know your thoughts.
>
> On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> Don't forget to opine here. To reiterate, I really don't expect the
>> proposal to be controversial. The text of the proposal is rather long, but
>> is made easy to read. So it shouldn't take too much of your time.
>>
>> /Arnaud
>>
>> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> I support acceptance.
>>>
>>> Simon
>>>
>>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> [ Proposal #583 https://github.com/ghc-proposals/ghc-proposals/pull/583
>>>> ]
>>>>
>>>> Our own Adam proposes to amend the design of the highly experimental
>>>> OverloadedRecordUpdate extension as had been designed in proposal #158 [
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ].
>>>>
>>>> Specifically, Adam proposes a modification of the type classes that
>>>> would back the extension.
>>>>
>>>> In the previous design the HasField class is defined as a lens:
>>>>
>>>> class HasField (n :: k) r a | r n -> a
>>>>   hasField :: r -> (a -> r, a)
>>>>
>>>> The proposal is to replace it by two classes (slightly simplified)
>>>>
>>>> class HasField (n :: k) r a | r n -> a
>>>>   hasField :: r -> a
>>>>
>>>> class SetField (n::k) r a | r n -> a
>>>>   modifyField :: (a -> a) -> r -> a
>>>>   setField :: a -> r -> a
>>>>
>>>> This is originally motivated by some performance consideration: the
>>>> prototype implementation of HasField as a lens can be very time consuming
>>>> because instances of HasFields are generated eagerly at record definition
>>>> sites, whereas the simple HasField instances can simply reuse the selectors
>>>> already generated by GHC. But a lot of thoughts have been put into the new
>>>> design, and my summary can certainly not do it justice: the proposal is
>>>> very well argumented.
>>>>
>>>> A point I'll make here is that the new design is actually parametric in
>>>> the data representation of the field type. Something that wasn't possible
>>>> in the original design.
>>>>
>>>> This proposal is not technically backward compatible, because the order
>>>> of argument in which OverloadedRecordUpdate expects the argument of
>>>> setField is changed. This is not essential to the proposal, but this is a
>>>> more consistent order argument with the rest of Haskell. And considering
>>>> that OverloadedRecordUpdate is very loudly advertised as experimental, I
>>>> recommend accepting this breakage.
>>>>
>>>> Overall the proposal is actually more backward compatible with GHC 9.8
>>>> than the original design, as the HasField class is left unchanged.
>>>>
>>>> Overall, the proposal looks quite reasonable to me, and well-argued. I
>>>> recommend acceptance.
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
>
>
> --
> 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/20230921/c59b1a25/attachment.html>