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

Tue Jan 22 18:41:27 UTC 2019

Hello,

I didn't hear any more thoughts on this one, so I will mark it as accepted.

-Iavor

On Tue, Jan 15, 2019 at 11:03 AM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hello,
>
> I am skeptical about the supposed overlap provided by functional
> dependencies that would be unsound with type families.   It would be
> extremely odd to accept a "functional" dependency that is not functional.
> And if it is functional, then it should not be unsound to generate evidence
> for it.   I am also not sure why one would use overlapping things for
> records---wouldn't that imply that a record has the same field multiple
> times somehow?   So, for me, the overlap benefit of FDs is rather suspect
> and I imagine that if it works it is an artifact of the current
> implementation rather than something that has been thought about deeply.
>
> On the other hand, I do think that the FD formulation captures more
> precisely what is intended in this situation, as the relation between types
> and fields is inherently partial (i.e., not all types have all fields).
>  As a result, if we used a type family, it would have to be a partial one.
> I know that these are commonly used, but I've never been quite comfortable
> with the way these "stuck" type families do not always result in a type
> error, and sometimes are treated silently as a ordinary types, even though
> they are not supposed to really correspond to any type at all.  This does
> not happen with constraints, which always result in a type error, if they
> can't be solved.
>
> To summarize the current state of the discussion:
>    - No one has complained about the main part of the proposal---adding an
> update functionality to the record class
>    - Simon M would prefer to use a type family for the record field:
> Simon, which formulation are you thinking of, 2 or 3 parameter class?
>    - Simon PJ would also prefer to use a type family, but due to some
> trade-offs is OK with using fun-deps for now.
>    - Iavor would prefer to stick with fun-dpes for the reasons above
> (also, the change seems quite orthogonal to the proposal)
>
> I haven't heard from anyone else.  While we are not in a big hurry, as I
> shepherd of this discussion I would like to move us in the direction of
> making a decision.
>
> So I am leaning towards accepting the proposal as is, unless Simon M or
> someone else objects strongly.  If you do, please speak up soon.
>
> Cheers,
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jan 9, 2019 at 12:19 AM Simon Marlow <marlowsd at gmail.com> wrote:
>
>> I defer to Simon's judgement on the details, however there's one point
>> that I think should be mentioned - unless we get some significant benefit
>> from using fundeps here, my preference would be to use type families
>> instead purely because it's one fewer extension for people to understand,
>> and this is core functionality that many people will likely encounter.
>> Fundeps are much less widely used than type families, and it would be nice
>> if we could keep them out of core abstractions so that those who don't need
>> them don't need to learn about them.
>>
>> Cheers
>> Simon
>>
>> On Tue, 8 Jan 2019 at 23:46, Simon Peyton Jones via
>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>
>>> 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> 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> *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
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190122/956087af/attachment-0001.html>