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 <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
