Re: New type of ($) operator in GHC 8.0 is problematic

Thank you for the reply! On Sun, 2016-02-14 at 22:58 -0500, Richard Eisenberg wrote:

This approach wouldn't quite work.

- It seems to kick in only when instantiating a Levity variable. That would not happen when using :info.

Obviously Levity variables should be defaulted to Lifted everywhere, including :info and :type. Is it possible or are there some technical limitations?

- It is possible to have unlifted types about even without -XMagicHash. -XMagicHash is simply a lexer extension, nothing more. By convention, we use the # suffix with unlifted things, but there's no requirement here. Having -XMagicHash thus imply a flag about the type system is bizarre.

OK, I always forget about that. But is not it a bug already? Usually we don't allow code that uses GHC-specific extensions to compile without a language pragma. Why we don't have such pragma for levity polymorphism? If we agree that we need a pragma, then we can find a way to introduce it without massive code breakage, e.g. we can add a warning to -Wcompat and make the pragma mandatory in 3 releases. Then we can have -fshow- runtime-rep as a temporary solution. It naturally solves an issue with Haddock -- it should show levity polymorphic type when an identifier is exported from a module with the pragma, and monomorphic type otherwise. Basically that is what haddock does for KindSignatures.

Furthermore, I'm not sure what the practical, user-visible improvement would be over the approach you include and the -fshow- runtime-rep idea.

The improvement is to keep ($) type as specified by Haskell2010 report (including :info) and never lie about it, but allow levity polymorphism when explicitly requested by user.

Richard

On Feb 13, 2016, at 11:40 AM, Yuras Shumovich wrote:

...

Thank you for the summary! The thread is too big to find anything in it.

I'd like to present a bit different approach, kind of a compromise, without lie and code breakage: introduce a language pragma for levity polymorphism and default levity polymorphic signatures to "*" when the pragma is not enabled.

For example, ($) could be defined like it is right now:

($)   :: forall (w :: GHC.Types.Levity) a (b :: TYPE w).      (a -> b) -> a -> b

But when it is used in a module without levity polymorphism enabled, "w" is defaulted to "Lifted", "b" gets kind "*", and ($) gets its old type:

($)   :: (a -> b) -> a -> b

So any use of ($) with types on kind "#" is disallowed.

But with levily polymorphism enabled, one will see the full type and use ($) with unlifted types. To prevent breakage of the existing code, MagicHash extension should by default imply levity polymorphism.

What do you think? Am I missing something?

Thanks, Yuras.

...

 * There are further questions regarding the appropriate kinds    of (->) and (.) [1]

 * Incidentally, there is a GHC or Haddock bug [2] which causes kind    signatures to be unnecessarily shown in documentation for some types,    exposing levities to the user.

The current plan to address this situation is as follows,

 * Introduce [3] a flag, -fshow-runtime-rep, which when disabled will    cause the pretty-printer to instantiate levity-polymorphic types as    lifted (e.g. resulting in *). This flag will be off by default,    meaning that users will in most cases see the usual lifted types    unless they explicitly request otherwise.

 * Fix the GHC/Haddock bug, restoring elision of unnecessary kind    signatures in documentation.

 * In the future we should seriously consider introducing an alternate    Prelude for beginners   As far as I can tell from the discussion, this was an acceptable solution to all involved. If there are any remaining objections or concerns let's discuss them in another thread.

Thanks to everyone who contributed to this effort.

Cheers,

- Ben

[1] https://ghc.haskell.org/trac/ghc/ticket/10343#comment:27 [2] https://ghc.haskell.org/trac/ghc/ticket/11567 [3] https://ghc.haskell.org/trac/ghc/ticket/11549 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs