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

[Boespflug, Mathieu]

Hi Ben,

thanks for the nice summary. I haven't been following all the details
in the meanderings of this thread, but perhaps someone can chime in
with an answer to this simple question:

* has it been discussed what type ($) should have in the Haddock's for
base? If so, will it the one GHCi shows by default, or the one GHCi
will show when -fshow-runtime-rep?

If the former, how is a user supposed to discover that ($) is in fact
more general than what the docs would tell you?

If the latter, wouldn't the Haddock's be just as confusing to
beginners as GHCi's output currently is? Wouldn't it be even more
confusing that the Haddock's and GHCi don't agree about what the type
of ($) really is?

Many thanks,
--
Mathieu Boespflug
Founder at http://tweag.io.


On 15 February 2016 at 04:58, Richard Eisenberg <eir at cis.upenn.edu> 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.
>
> - 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
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs