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

[Arnaud Spiwack]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230921/721d4533/attachment.html>