Hello, does anyone else have any input on this proposal? There has been some discussion on Simon's point about using a type-family instead of a fun-dep. The outcome of the discussion is a little unclear, but here is a very brief summary to the best of my understanding: * Either approach works, but with the current GHC implementations both approaches have some pros and some cons. * Fun-deps (used in the current design) are a bit more restrictive as they do not produce evidence at the moment * There are two ways to use type families instead of fun-deps: a) the class has 2 parameters, and the third is computed from them using a type family b) the class remains with 3 parameters, but it gets a super-class constraint, where a type-family encodes the functional dependency * Either type family encoding leads to types that look more verbose, both in errors and inferred types. * There are some ideas about how this might be improved for type families in general (see #16070) The choice of type-families/fun-deps is quite orthogonal to the original proposal, which is about adding a way to update records. We were discussing it, because it is quite tempting to roll-up multiple interface breaking changes into one. In the interest of making progress, my vote would be to accept the proposal as is, and delay switching to type families to a separate proposal, which might look better once the improvements in #16070 are figured out. What does everyone else think? -Iavor On Wed, Dec 19, 2018 at 1:04 AM Simon Peyton Jones <simonpj@microsoft.com> wrote:
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-4485200...
Simon
*From:* ghc-steering-committee <ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Iavor Diatchki *Sent:* 18 December 2018 18:02 *To:* ghc-steering-committee <ghc-steering-committee@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