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

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 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 *On Behalf Of *Richard Eisenberg *Sent:* 14 March 2019 23:46 *To:* Iavor Diatchki *Cc:* ghc-steering-committee@haskell.org; Joachim Breitner < mail@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 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 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/...

I like that it actually simplifies the UI (by removing :type +v), so I recommend acceptance.

Cheers, Joachim -- Joachim Breitner mail@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee