[ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept

Wed Apr 17 17:15:07 UTC 2019

I am fine with the change.

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).

On Wed, Apr 17, 2019 at 12:02 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi Iavor,
>
> have these explanations helped your understanding here? Do they address
> your concerns?
>
> Cheers,
> Joachim
>
> Am Freitag, den 15.03.2019, 14:03 -0400 schrieb Richard Eisenberg:
> > On Mar 15, 2019, at 1:04 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
> > >
> > > This is a bit orthogonal, but what would you expect to see in this
> case:
> > >
> > > type T b = Bool
> > > bar :: (a ~ Int) => a -> T b -> a
> > >
> > > :t bar
> >
> > Without -fprint-explicit-foralls: (a ~ Int) => a -> T b -> a
> > With -fprint-explicit-foralls: forall a b. (a ~ Int) => a -> T b -> a
> >
> > > :t bar @Bool
> >
> > Without -fprint-explicit-foralls: (Bool ~ Int) => Bool -> T b -> Bool
> > With -fprint-explicit-foralls: forall b. (Bool ~ Int) => Bool -> T b ->
> Bool
> >
> > > I guess the answer to these depends on if `b` is quantified or not.
> >
> > b *is* quantified -- the quantification happens on the type as the user
> writes it.
> >
> > Richard
> >
> > >
> > >
> > >
> > >
> > > On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
> > > > This looks particularly confusing without the explicit `forall`,
> although it seems questionable either way.
> > > >
> > > > Why?  GHC often suppresses foralls when printing types; and had
> -fprint-explicit-foralls to stop doing that.
> > > >
> > > > Simon
> > > >
> > > > From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
> > > > Sent: 14 March 2019 23:46
> > > > To: Iavor Diatchki <iavor.diatchki at gmail.com>
> > > > Cc: ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> > > > Subject: Re: [ghc-steering-committee] #179: Tweak the printing of
> foralls, recommendation: accept
> > > >
> > > >
> > > > > On Mar 14, 2019, at 6:18 PM, Iavor Diatchki <
> iavor.diatchki at gmail.com> wrote:
> > > > >
> > > > > bar :: forall a b. (a ~ Int) => a -> b -> a
> > > > >
> > > > > Is it the case that `:t bar @Bool` will print
> > > > >
> > > > > bar :: (Bool ~ Int) => Bool -> b -> Bool
> > > > >
> > > > > This looks particularly confusing without the explicit `forall`,
> although it seems questionable either way.
> > > >
> > > >
> > > > 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`.
> > > >
> > > > 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.
> > > >
> > > > Richard
> > > >
> > > >
> > > > >
> > > > > -Iavor
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <
> mail at joachim-breitner.de> wrote:
> > > > > > Dear Committee,
> > > > > >
> > > > > > Richard, in collarboration with Simon PJ, proposes some tweaks
> to how
> > > > > > foralls are printed by GHC.
> > > > > >
> > > > > > In particular, whenever a type variable is printed with an
> forall, it
> > > > > > is printed with {a} unless it is a specified variable. And there
> are
> > > > > > tweaks to what :type does with its argument that makes it more
> useful,
> > > > > > and obviates the need for a separate :type +v.
> > > > > >
> https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst
> > > > > >
> > > > > > I like that it actually simplifies the UI (by removing :type
> +v), so I
> > > > > > recommend acceptance.
> > > > > >
> > > > > > Cheers,
> > > > > > Joachim
> > > > > > --
> > > > > > Joachim Breitner
> > > > > >   mail at joachim-breitner.de
> > > > > >   http://www.joachim-breitner.de/
> > > > > >
> > > > > > -----BEGIN PGP SIGNATURE-----
> > > > > >
> > > > > > iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7
> > > > > > 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN
> > > > > > R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM
> > > > > > DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+
> > > > > > cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA
> > > > > > hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr
> > > > > > mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M
> > > > > > 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE
> > > > > > r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt
> > > > > > fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H
> > > > > > c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05
> > > > > > rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg=
> > > > > > =1qbg
> > > > > > -----END PGP SIGNATURE-----
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > ghc-steering-committee at haskell.org
> > > > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > >
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > ghc-steering-committee at haskell.org
> > > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > >
> > > >
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20190417/c8b3c594/attachment-0001.html>