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

Richard Eisenberg 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.

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
> 



More information about the ghc-devs mailing list