<div dir="ltr">I am fine with the change.<div><br></div><div>Something that I've realized from the last few discussions we've had is that the underlying feature I find questionable is the bit where GHC infers a variable ordering from the written signatures (left to write, but kinds before types, and synonyms matter). </div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 17, 2019 at 12:02 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</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">Hi Iavor,<br>
<br>
have these explanations helped your understanding here? Do they address<br>
your concerns?<br>
<br>
Cheers,<br>
Joachim<br>
<br>
Am Freitag, den 15.03.2019, 14:03 -0400 schrieb Richard Eisenberg:<br>
> On Mar 15, 2019, at 1:04 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:<br>
> > <br>
> > This is a bit orthogonal, but what would you expect to see in this case:<br>
> > <br>
> > type T b = Bool<br>
> > bar :: (a ~ Int) => a -> T b -> a<br>
> > <br>
> > :t bar<br>
> <br>
> Without -fprint-explicit-foralls: (a ~ Int) => a -> T b -> a<br>
> With -fprint-explicit-foralls: forall a b. (a ~ Int) => a -> T b -> a<br>
> <br>
> > :t bar @Bool<br>
> <br>
> Without -fprint-explicit-foralls: (Bool ~ Int) => Bool -> T b -> Bool<br>
> With -fprint-explicit-foralls: forall b. (Bool ~ Int) => Bool -> T b -> Bool<br>
> <br>
> > I guess the answer to these depends on if `b` is quantified or not.<br>
> <br>
> b *is* quantified -- the quantification happens on the type as the user writes it.<br>
> <br>
> Richard<br>
> <br>
> > <br>
> > <br>
> > <br>
> > <br>
> > On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br>
> > > This looks particularly confusing without the explicit `forall`, although it seems questionable either way.<br>
> > >  <br>
> > > Why?  GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that.<br>
> > >  <br>
> > > Simon<br>
> > >  <br>
> > > From: ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>> On Behalf Of Richard Eisenberg<br>
> > > Sent: 14 March 2019 23:46<br>
> > > To: Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>><br>
> > > Cc: <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>
> > > Subject: Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept<br>
> > >  <br>
> > >  <br>
> > > > 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:<br>
> > > >  <br>
> > > > bar :: forall a b. (a ~ Int) => a -> b -> a<br>
> > > >  <br>
> > > > Is it the case that `:t bar @Bool` will print<br>
> > > >  <br>
> > > > bar :: (Bool ~ Int) => Bool -> b -> Bool<br>
> > > >  <br>
> > > > This looks particularly confusing without the explicit `forall`, although it seems questionable either way.<br>
> > > <br>
> > >  <br>
> > > 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`.<br>
> > >  <br>
> > > 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.<br>
> > >  <br>
> > > Richard<br>
> > > <br>
> > > <br>
> > > >  <br>
> > > > -Iavor<br>
> > > >  <br>
> > > >  <br>
> > > >  <br>
> > > > 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:<br>
> > > > > 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" rel="noreferrer" 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>
> > > > > -- <br>
> > > > > Joachim Breitner<br>
> > > > >   <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> > > > >   <a href="http://www.joachim-breitner.de/" rel="noreferrer" 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" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > > > <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" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > > <br>
> > >  <br>
> <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" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<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" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>