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

[Yuras Shumovich]

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 <shumovichy at 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 at haskell.org
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > > _______________________________________________
> > > ghc-devs mailing list
> > > ghc-devs at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > > 
> >