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

[Ben Gamari]

"Boespflug, Mathieu" <m at tweag.io> writes:

>> As far as I know, there is currently know way to
>> do this in 7.10.
>>
>> Given how much backlash there has been to changing the type of ($), ...
>
> Keep in mind... as we saw with FTP, that in this community it's often
> unclear just how large or tiny a group of people represent when
> they're vocal (could be an outright majority, could in fact be just a
> handful... hard to tell). ;)
>
This is very true. I wish we had better instruments for judging
consensus. Sadly it seems this is a problem that has long resisted
solution.

>> I'd be fine not using -fshow-runtime-rep during the core library
>> haddock builds. In effect the message to users would be,
>>
>>     "yes, unboxed types exist and they are now on sound theoretical
>>     footing, but they are still largely an implementation detail, just as
>>     they have always been. If you want to use them you need to know
>>     where to look."
>
> When that last sentence is expanded out a bit to explain what "know
> where to look means", it means
>
> "yes, unboxed types exist and they are now on sound theoretical
> footing [...]. If you want to use them you need to know where to look,
> i.e. pass -fshow-runtime-types to GHCi every time, and compile your
> own Haddock's, keep them safe somewhere on your computer and point
> your browser there instead, because
> https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ is not
> going to tell you where you can use it."
>
> All in a laudable effort to present less information to beginners
> out-of-the-box, IMHO the story is starting to look awefully
> complicated for Haskell practitioners, i.e.
> beginners-a-little-while-ago...
>
Well said.

> Said another way, sounds to me like we're in a case of: avoiding
> surprise now begets bigger surprise later (and wasted time trying to
> discover all these myriad flags whose sole existence was to pretend to
> her/him that things are simpler than they really are, and then dealing
> with their consequences...) when the beginner becomes practitioner.
>
Sure, but there is a trade-off here. Even in performance-sensitive
applications unboxed types don't appear that frequently. Now, perhaps
this will change as these types become well-behaved members of the
language. However at the moment I'm not convinced that the consistency
that showing this polymorphism to all users pays for itself. Afterall,
the signatures are significantly noiser than the current monomorphic
forms.

However, I think we should certainly reconsider this once we have had
some experience working with these types in the post-levity-polymorphic
world and have worked out how to deal with some of the more human issues
that they bring.

<aside>
At the moment levity-polymorphic types are a fair bit more noisy
than their lifted counterparts. I think this is a problem which raises
an interesting of information presentation. While reading documentation,
I find that I usually read from the right to left. That is, if faced
with given

    foldMap :: forall a m t. (Foldable t, Monoid m) => (a -> m) -> t a -> m

My eye will typically follow a trajectory of,

  1. start with the binder, `foldMap`

  2. look at the shape of the type, `(a -> m) -> t a -> m`

  3. refer to the context to see what is demanded of these types

  4. look back to the shape, folding in knowledge from the constraints

  5. if there are still questions, refer to type variable signatures in
     the forall clause.

  6. repeat 3 through 5 until satisfied

Unfortunately it takes a fair amount of visual processing for even a
seasoned user to segment the signature into these four pieces. Moreover,
the majority of the signature is context and the forall clause, which
are arguably the parts that one looks at least.

An easy way to counteract this in Haddock would be to remove emphasis
from the forall clause (either reduce its contrast or collapse it
entirely).

In the case of typeclass polymorphism haddock tries to make types easier
to grok by presenting specializations of typeclass methods in instance
documentation. While I'm not sure that this exact scheme would help much
for levity, I wonder what other ideas in this vein we could try.

In the case of GHCi, I suspect something like Richard's suggestion of a
more interactive console.
</aside>

>> Perhaps this can be revisited at some point in the future when we have a
>> better story for a beginner's Prelude but for now I'm not sure we want
>> to subject everyone to these new types.
>
> TBH I'm fairly skeptical about the "Prelude for beginners" idea.
> Things like e.g. the AMP require that everyone has the same idea of
> what the definition of the Monad class is. Yet it's not like you're
> either a beginner or you're not: it's a continuum (we're all
> beginners, just some less than others...). When beginners start
> uploading new packages on Hackage (and I hope they do), but do so
> using BeginnerPrelude because that's what they were taught, then we
> start having to make the (artificially created) "beginner world" and
> the "real world" agree. If I define an instance of a BeginnerPrelude
> class in package A, it might not be exploitable in package B. Worse,
> if what we're really talking about is beginner-base, then what happens
> when they both define their own Data.List module? So in the end the
> scope of a BeginnerPrelude may be very limited indeed.
>
> If a beginner Prelude is really the right way forward, then surely one
> of the many authors of Haskell books would have put one forward by now
> and recommend using that?
>
>  But perhaps this is a topic for another thread...
>
Indeed. I'll just say that I envision that a beginner's prelude would be
for learning and nothing more. The goal is that it would be used in the
first dozen hours of picking up the language and nothing more.

I'd be interested to hear what Richard had in mind when he has time
again.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160216/70eafeaa/attachment.sig>