[ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`"

[Simon Peyton Jones]

Iavor

I’m broadly happy, but I would like us (and the proposers) to discuss the question of using a type family instead of a fundep.  See my comment at https://github.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-448520004

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 18 December 2018 18:02
To: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`"

Hello,

let's start the discussion on proposal #158.

After some discussion on the pull request the proposal was changed, so that instead of adding another method, it now proposes to remove the existing method `getField`, and add a new method `hasField`, which allows to both access and change the value of a field.  After the proposal the class would look like this

-- `x` is the name of the field, `r` is the type of the record, `a` is the type of the field
class HasField x r a | x r -> a where
  hasField :: r -> (a -> r, a)

In addition, we'd provide two functions `getField` and `setField` which are defined in terms of `hasField`.    The proposal may break existing code, if it defines manual instances of `HasField`, however, code that just uses the functionality will continue working as before.   `HasField` is relatively new, and there aren't many reasons to define custom instances of it, so it is expected that breaking code would not be a big issue.

This seems like a reasonably simple change, that adds new functionality, so I recommend that we accept the change.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20181219/0b01fb9a/attachment-0001.html>