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

[Iavor Diatchki]

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>
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
>
>
>
> 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/20190108/a68b45f0/attachment.html>