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

[Yuras Shumovich]

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