
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
Hi Iavor,
have these explanations helped your understanding here? Do they address your concerns?
Cheers, Joachim
On Mar 15, 2019, at 1:04 PM, Iavor Diatchki
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@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
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
The direction in the proposal came about in wondering if it's
Am Freitag, den 15.03.2019, 14:03 -0400 schrieb Richard Eisenberg: though the next variable to be instantiated is `a`. This is why we have `:type +v`. 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/...
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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee