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

[Simon Peyton Jones]

Yes, I’m fine with accepting as-is.  Actually the discussion has been quite illuminating.  I learned


  *   An idea for improving inferred types (Trac #16070)
  *   An understanding that
     *   Type families are in some ways more expressive because they support evidence
     *   But fundeps allow overlap (which for soundness type families must eschew) and that allows a different kind of expressiveness.
So the two overlap, but neither subsumes the other.  And I think the choice is fundamental; the overlap stuff in fundeps is allowed precisely because it only affect unification, and doesn’t turn into evidence.

  *   For HasField we don’t need overlap.
  *   However, even if we used a type-family encoding, a 3-parameter class is probably best, because it leads to briefer types.
  *   And, absent #16070, the error messages with fundeps are better, and the extra expressiveness of type families has not (yet) become important for HasField.

Conclusion: use fundeps for now.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 08 January 2019 23:10
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`"

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 at microsoft.com<mailto:simonpj at 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-448520004<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F158%23issuecomment-448520004&data=02%7C01%7Csimonpj%40microsoft.com%7C93e0092457d2468378cf08d675be71fd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636825858153743988&sdata=VvDRQjpINBfDlgwjWVyeokmJSIi3ZOdPvqXKW2gbtSs%3D&reserved=0>

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto: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<mailto: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/20190108/4fce7607/attachment-0001.html>