"Boespflug, Mathieu"
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