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

[Simon Peyton Jones]

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