<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">ghc-steering-committee@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple">
<div class="m_-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="m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>An idea for improving inferred types (Trac #16070)<u></u><u></u></span></li><li class="m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>An understanding that<u></u><u></u></span>
<ul style="margin-top:0cm" type="circle">
<li class="m_-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="m_-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:54.0pt"><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="m_-5730158583245005848MsoListParagraph" style="margin-left:0cm"><span>For HasField we don’t need overlap.<u></u><u></u></span></li><li class="m_-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="m_-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:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 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:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Iavor</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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:12.0pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Simon</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><u></u><u></u></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 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:6.0pt">Hello,<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt">let's start the discussion on proposal #158.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt">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:6.0pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt">-- `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:6.0pt">class HasField x r a | x r -> a where<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt"> hasField :: r -> (a -> r, a)<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt">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:6.0pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt">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:6.0pt"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:6.0pt">-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>