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

[Arnaud Spiwack]

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