This approach wouldn't quite work. - It seems to kick in only when instantiating a Levity variable. That would not happen when using :info.
- 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. Furthermore, I'm not sure what the practical, user-visible improvement would be over the approach you include and the -fshow-runtime-rep idea. Richard On Feb 13, 2016, at 11:40 AM, Yuras Shumovich <shumovi...@gmail.com> 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 > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs