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@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@haskell.org> On Behalf Of Richard Eisenberg
Sent: 14 March 2019 23:46
To: Iavor Diatchki <iavor.diatchki@gmail.com>
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 <iavor.diatchki@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@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@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