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

[Iavor Diatchki]

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.

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
:t bar @Bool

I guess the answer to these depends on if `b` is quantified or not.





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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190315/71d43749/attachment.html>