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