<div dir="ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>To summarize the current state of the discussion:</div><div> - No one has complained about the main part of the proposal---adding an update functionality to the record class</div><div> - 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?</div><div> - Simon PJ would also prefer to use a type family, but due to some trade-offs is OK with using fun-deps for now.</div><div> - Iavor would prefer to stick with fun-dpes for the reasons above (also, the change seems quite orthogonal to the proposal)</div><div> </div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>-Iavor</div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 9, 2019 at 12:19 AM Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 8 Jan 2019 at 23:46, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div class="gmail-m_-6876599906379484983m_-5730158583245005848WordSection1">
<p class="MsoNormal"><span>Yes, I’m fine with accepting as-is. Actually the discussion has been quite illuminating. I learned<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-6876599906379484983m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>An idea for improving inferred types (Trac #16070)<u></u><u></u></span></li><li class="gmail-m_-6876599906379484983m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>An understanding that<u></u><u></u></span>
<ul style="margin-top:0cm" type="circle">
<li class="gmail-m_-6876599906379484983m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>Type families are in some ways more expressive because they support evidence<u></u><u></u></span></li><li class="gmail-m_-6876599906379484983m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>But fundeps allow overlap (which for soundness type families must eschew) and that allows a different kind of expressiveness.<u></u><u></u></span></li></ul>
</li></ul>
<p class="MsoNormal" style="margin-left:54pt"><span>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.<u></u><u></u></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-6876599906379484983m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>For HasField we don’t need overlap.<u></u><u></u></span></li><li class="gmail-m_-6876599906379484983m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>However, even if we used a type-family encoding, a 3-parameter class is probably best, because it leads to briefer types.<u></u><u></u></span></li><li class="gmail-m_-6876599906379484983m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>And, absent #16070, the error messages with fundeps are better, and the extra expressiveness of type families has not (yet) become important
for HasField.<u></u><u></u></span></li></ul>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Conclusion: use fundeps for now.<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>>
<br>
<b>Sent:</b> 08 January 2019 23:10<br>
<b>To:</b> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
<b>Cc:</b> ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
<b>Subject:</b> Re: [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`"<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hello,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">does anyone else have any input on this proposal? <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> * Either approach works, but with the current GHC implementations both approaches have some pros and some cons.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> * Fun-deps (used in the current design) are a bit more restrictive as they do not produce evidence at the moment<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> * There are two ways to use type families instead of fun-deps:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> a) the class has 2 parameters, and the third is computed from them using a type family<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> b) the class remains with 3 parameters, but it gets a super-class constraint, where a type-family encodes the functional dependency<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> * Either type family encoding leads to types that look more verbose, both in errors and inferred types.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> * There are some ideas about how this might be improved for type families in general (see #16070)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">because it is quite tempting to roll-up multiple interface breaking changes into one.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">which might look better once the improvements in #16070 are figured out.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">What does everyone else think?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-Iavor<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, Dec 19, 2018 at 1:04 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Iavor</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12pt">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
<a href="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" target="_blank">
https://github.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-448520004</a></span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12pt">Simon</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>>
<b>On Behalf Of </b>Iavor Diatchki<br>
<b>Sent:</b> 18 December 2018 18:02<br>
<b>To:</b> ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
<b>Subject:</b> [ghc-steering-committee] Discussion for #158 "Add `setFild` to `HasField`"</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt">Hello,<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:6pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt">let's start the discussion on proposal #158.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt">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<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt">-- `x` is the name of the field, `r` is the type of the record, `a` is the type of the field<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt">class HasField x r a | x r -> a where<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt"> hasField :: r -> (a -> r, a)<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt">This seems like a reasonably simple change, that adds new functionality, so I recommend that we accept the change.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6pt">-Iavor <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
</blockquote></div>