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

[Vladislav Zavialov]

In light of the recent discussion, I take that back. It turns out that type
inference is not the only problem with type-changing updates. There's also
an issue with multi-field type-changing updates, and it's more severe (I
don't see a clear way forward).

So now I'm now (weakly) in favor of the proposal as it is. SetField can't
handle type-changing updates -- so be it. We need a bigger hammer to deal
with type-changing updates.

Vlad

On Thu, Sep 21, 2023 at 11:12 AM Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> 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/f110995e/attachment.html>