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

Richard Eisenberg rae at richarde.dev
Fri Mar 15 18:03:01 UTC 2019



> 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 <mailto: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 <mailto: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 <mailto:iavor.diatchki at gmail.com>>
> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de <mailto: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 <mailto: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 <mailto: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 <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 <mailto:mail at joachim-breitner.de>
>   http://www.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 <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/a956a216/attachment-0001.html>


More information about the ghc-steering-committee mailing list