New type of ($) operator in GHC 8.0 is problematic
eir at cis.upenn.edu
Mon Feb 15 03:58:09 UTC 2016
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.
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
> 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
> :: (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?
>> * There are further questions regarding the appropriate kinds
>> of (->) and (.) 
>> * Incidentally, there is a GHC or Haddock bug  which causes kind
>> signatures to be unnecessarily shown in documentation for some
>> exposing levities to the user.
>> The current plan to address this situation is as follows,
>> * Introduce  a flag, -fshow-runtime-rep, which when disabled will
>> cause the pretty-printer to instantiate levity-polymorphic types
>> 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
>> 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.
>> - Ben
>>  https://ghc.haskell.org/trac/ghc/ticket/10343#comment:27
>>  https://ghc.haskell.org/trac/ghc/ticket/11567
>>  https://ghc.haskell.org/trac/ghc/ticket/11549
>> ghc-devs mailing list
>> ghc-devs at haskell.org
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs