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

[Arnaud Spiwack]

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