On Mon, 2016-02-15 at 14:00 +0300, Yuras Shumovich wrote: > 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.
Correction: we don't need -fshow-runtime-rep even temporary, -XLevilyPolymorphism flag in ghci will be sufficient. > > 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
