<div dir="ltr"><div dir="ltr">I just mean that without explicit foralls the fact that there is another quantified variable is not quite obvious, and so to me it looks quite surprising that the context didn't get simplified.</div><div dir="ltr"><br><div>This is a bit orthogonal, but what would you expect to see in this case:</div><div><br></div><div>type T b = Bool</div><div>bar :: (a ~ Int) => a -> T b -> a<br></div><div><br></div><div>:t bar</div><div>:t bar @Bool</div><div><br></div><div>I guess the answer to these depends on if `b` is quantified or not.</div><div><br></div><div><br></div><div><br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.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 lang="EN-GB">
<div class="gmail-m_6376247681929278253WordSection1">
<p class="MsoNormal" style="margin-left:36pt"><span style="font-size:9pt;font-family:Helvetica,sans-serif">This looks particularly confusing without the explicit `forall`, although it seems questionable either way.<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Why? GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that.<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"> 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>Richard Eisenberg<br>
<b>Sent:</b> 14 March 2019 23:46<br>
<b>To:</b> Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>><br>
<b>Cc:</b> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>; Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>><br>
<b>Subject:</b> Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">On Mar 14, 2019, at 6:18 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">bar :: forall a b. (a ~ Int) => a -> b -> a<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">Is it the case that `:t bar @Bool` will print<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">bar :: (Bool ~ Int) => Bool -> b -> Bool<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">This looks particularly confusing without the explicit `forall`, although it seems questionable either way.<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's
OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why
we have `:type +v`.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized
we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Richard<u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">-Iavor<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u> <u></u></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<u></u><u></u></span></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">
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">Dear Committee,<br>
<br>
Richard, in collarboration with Simon PJ, proposes some tweaks to how<br>
foralls are printed by GHC.<br>
<br>
In particular, whenever a type variable is printed with an forall, it<br>
is printed with {a} unless it is a specified variable. And there are<br>
tweaks to what :type does with its argument that makes it more useful,<br>
and obviates the need for a separate :type +v.<br>
<a href="https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst" target="_blank">https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst</a><br>
<br>
I like that it actually simplifies the UI (by removing :type +v), so I<br>
recommend acceptance.<br>
<br>
Cheers,<br>
Joachim<br>
--<span class="gmail-m_6376247681929278253apple-converted-space"> </span><br>
Joachim Breitner<br>
<span class="gmail-m_6376247681929278253apple-converted-space"> </span><a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<span class="gmail-m_6376247681929278253apple-converted-space"> </span><a href="http://www.joachim-breitner.de/" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7<br>
9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN<br>
R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM<br>
DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+<br>
cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA<br>
hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr<br>
mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M<br>
9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE<br>
r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt<br>
fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H<br>
c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05<br>
rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg=<br>
=1qbg<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<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" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><u></u><u></u></span></p>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">_______________________________________________<br>
ghc-steering-committee mailing list<br>
</span><a href="mailto:ghc-steering-committee@haskell.org" target="_blank"><span style="font-size:9pt;font-family:Helvetica,sans-serif">ghc-steering-committee@haskell.org</span></a><span style="font-size:9pt;font-family:Helvetica,sans-serif"><br>
</span><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank"><span style="font-size:9pt;font-family:Helvetica,sans-serif">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</span></a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</blockquote></div>