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

[Vladislav Zavialov]

I'm against the proposal in its current form because it does not support
type-changing update and is not forward-compatible with it. Fortunately, it
is not hard to fix this, as Adam points out in a GitHub comment:

> I suppose one thing we could do now would be to add the parameters for
type-changing update already, but restrict the constraint solver behaviour,
e.g. define the classes SetField x s t a b and type SetField' x r a =
SetField x r r a a, but have the constraint solver always unify s ~ t and a
~ b when solving constraints. That would limit (but not necessarily
eliminate) the breakage when generalising the constraint solver.

Let's do it this way to avoid a breaking change in the future!

Vlad

On Thu, Sep 21, 2023 at 10:35 AM Chris Dornan <chris at chrisdornan.com> wrote:

> +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
>>
> _______________________________________________
> 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/aa47514d/attachment-0001.html>