Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

I have made a ticket #11549 (https://ghc.haskell.org/trac/ghc/ticket/11549) requesting a -fshow-runtime-rep flag (recalling that the name levity will soon be outdated) as described in this thread. I will make sure this gets in for the release of 8.0.
Other points:
- You're quite right that (.) could be generalized. But I'll wait for someone to really want this.
- I don't have a non-contrived example of the use of ($) with unlifted types. It's quite possible that when adding the dirty runST hack, it was observed that an unlifted type would be OK. At that point, the type of ($) didn't need to become so elaborate. And now we're just trying not to change old (but perhaps unrequested) behavior.
- For the record, this debate is entirely unrelated to the runST impredicativity hack. (Except, as noted above, perhaps in history.) That hack remains, basically unchanged.
- On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka
I would call this a simplification rather than a lie.
This is a very convincing argument. - Thanks, also, for the voice of support. What I love about the Haskell community is that we can have an impassioned debate full of strong opinions, and it all very rarely devolves into a proper flame war. All the posts I've seen in this thread have been constructive and helpful. Thanks. Richard

Hi Richard and devs,
What a wonderful (#11549) !
This is a beautiful solution for beginners/newcomers.
Beginners will not confuse and they can gradually go ahead.
I extremely appreciate that you are continuously improving the ghc for us.
Thank you very much,
Takenobu
2016-02-07 0:17 GMT+09:00 Richard Eisenberg
I have made a ticket #11549 (https://ghc.haskell.org/trac/ghc/ticket/11549) requesting a -fshow-runtime-rep flag (recalling that the name levity will soon be outdated) as described in this thread. I will make sure this gets in for the release of 8.0.
Other points:
- You're quite right that (.) could be generalized. But I'll wait for someone to really want this.
- I don't have a non-contrived example of the use of ($) with unlifted types. It's quite possible that when adding the dirty runST hack, it was observed that an unlifted type would be OK. At that point, the type of ($) didn't need to become so elaborate. And now we're just trying not to change old (but perhaps unrequested) behavior.
- For the record, this debate is entirely unrelated to the runST impredicativity hack. (Except, as noted above, perhaps in history.) That hack remains, basically unchanged.
- On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka
wrote: I would call this a simplification rather than a lie.
This is a very convincing argument.
- Thanks, also, for the voice of support. What I love about the Haskell community is that we can have an impassioned debate full of strong opinions, and it all very rarely devolves into a proper flame war. All the posts I've seen in this thread have been constructive and helpful. Thanks.
Richard _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Hi,
I understood one more point. (I share here.)
The Prelude library document for ghc 8.0 is already well described for
beginners/newcomers.
* The ($)'s signature of 8.0.1 is already simple (not include forall ...).
* The Bool's kind of 8.0.1 is already represented with "TYPE Lifted"
(changed from '*').
ghc7.8.4 [1]:
data Bool :: *
foldr :: (a -> b -> b) -> b -> [a] -> b
($) :: (a -> b) -> a -> b
ghc7.10.4 [2]:
data Bool :: *
foldr :: (a -> b -> b) -> b -> t a -> b
($) :: (a -> b) -> a -> b
ghc8.0.1-rc2 [3]:
data Bool :: TYPE Lifted
foldr :: (a -> b -> b) -> b -> t a -> b
($) :: (a -> b) -> a -> b
[1]
https://downloads.haskell.org/~ghc/7.8.4/docs/html/libraries/base-4.7.0.2/Pr...
[2]
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.8.2.0/P...
[3]
https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0....
Regards,
Takenobu
2016-02-08 19:08 GMT+09:00 Takenobu Tani
Hi Richard and devs,
What a wonderful (#11549) ! This is a beautiful solution for beginners/newcomers. Beginners will not confuse and they can gradually go ahead.
I extremely appreciate that you are continuously improving the ghc for us.
Thank you very much, Takenobu
2016-02-07 0:17 GMT+09:00 Richard Eisenberg
: I have made a ticket #11549 ( https://ghc.haskell.org/trac/ghc/ticket/11549) requesting a -fshow-runtime-rep flag (recalling that the name levity will soon be outdated) as described in this thread. I will make sure this gets in for the release of 8.0.
Other points:
- You're quite right that (.) could be generalized. But I'll wait for someone to really want this.
- I don't have a non-contrived example of the use of ($) with unlifted types. It's quite possible that when adding the dirty runST hack, it was observed that an unlifted type would be OK. At that point, the type of ($) didn't need to become so elaborate. And now we're just trying not to change old (but perhaps unrequested) behavior.
- For the record, this debate is entirely unrelated to the runST impredicativity hack. (Except, as noted above, perhaps in history.) That hack remains, basically unchanged.
- On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka
wrote: I would call this a simplification rather than a lie.
This is a very convincing argument.
- Thanks, also, for the voice of support. What I love about the Haskell community is that we can have an impassioned debate full of strong opinions, and it all very rarely devolves into a proper flame war. All the posts I've seen in this thread have been constructive and helpful. Thanks.
Richard _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Takenobu Tani
Hi,
I understood one more point. (I share here.) The Prelude library document for ghc 8.0 is already well described for beginners/newcomers.
* The ($)'s signature of 8.0.1 is already simple (not include forall ...). * The Bool's kind of 8.0.1 is already represented with "TYPE Lifted" (changed from '*').
ghc7.8.4 [1]:
data Bool :: * foldr :: (a -> b -> b) -> b -> [a] -> b ($) :: (a -> b) -> a -> b
ghc7.10.4 [2]:
data Bool :: * foldr :: (a -> b -> b) -> b -> t a -> b ($) :: (a -> b) -> a -> b
ghc8.0.1-rc2 [3]:
data Bool :: TYPE Lifted
To clarify, this isn't actually a change; `*` is merely a synonym for `TYPE 'Lifted`. Moreover, I believe this is a bug. In general we should continue to show `*` for plain lifted types. If you look at other types in the -rc2 haddocks you will see that they are indeed rendered as they were in previous releases, with no kind annotation at all. Bool is likely only rendered differently as it is a wired-in type; we'll need to fix this. I've opened #11567 to track this issue. Cheers, - Ben

Hi Ben,
Thank you for explanation.
Sorry, I was misunderstood that ghc8 changes representation of '*'.
(In addition to the Bool, but also Int, Float,..)
There are also followings:
Alternative f => Monoid (Alt (TYPE Lifted) f a)
Functor (Proxy (TYPE Lifted))
Foldable (Const (TYPE Lifted) m)
Thank you very much,
Takenobu
2016-02-11 21:33 GMT+09:00 Ben Gamari
Takenobu Tani
writes: Hi,
I understood one more point. (I share here.) The Prelude library document for ghc 8.0 is already well described for beginners/newcomers.
* The ($)'s signature of 8.0.1 is already simple (not include forall ...). * The Bool's kind of 8.0.1 is already represented with "TYPE Lifted" (changed from '*').
ghc7.8.4 [1]:
data Bool :: * foldr :: (a -> b -> b) -> b -> [a] -> b ($) :: (a -> b) -> a -> b
ghc7.10.4 [2]:
data Bool :: * foldr :: (a -> b -> b) -> b -> t a -> b ($) :: (a -> b) -> a -> b
ghc8.0.1-rc2 [3]:
data Bool :: TYPE Lifted
To clarify, this isn't actually a change; `*` is merely a synonym for `TYPE 'Lifted`.
Moreover, I believe this is a bug. In general we should continue to show `*` for plain lifted types. If you look at other types in the -rc2 haddocks you will see that they are indeed rendered as they were in previous releases, with no kind annotation at all. Bool is likely only rendered differently as it is a wired-in type; we'll need to fix this. I've opened #11567 to track this issue.
Cheers,
- Ben
participants (3)
-
Ben Gamari
-
Richard Eisenberg
-
Takenobu Tani