[Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic

[Richard A. O'Keefe]

> Just as a thought experiment: The FTP had a landslide support on the 
> libraries list.
> How would it have fared on a Haskell-Edu list?

Judging by the list of changes at 
https://wiki.haskell.org/Foldable_Traversable_In_Prelude
the changes were mostly some extra classes (Monoid, Foldable, 
Traverseable) showing up
in Prelude and a bunch of type changes to functions:
... [x] ...   changing to (Foldable t) => ... t x ...
... [x] ...   changing to (Traverseable t) => ... t x ...

This is actually quite an interesting change.
Using the same names *consistently* across a wide range of types
makes programs easier to write and easier to read.
 From an educational point of view, you can't say

   "We didn't need the Prelude to write `all` for us.
    We could have written

     all p (x:xs) = p x && all p xs
     all _ [] = True
   "

any more because that has the wrong (old, list-specific) type.
You *can* say

    "We could have written

     all = foldr True (&&)
   "

So you lose a lesson that comes somewhere near the beginning,
when you are still trying to get across the idea of higher order
functions and lazy evaluation, and gain a lesson that comes
much later, about the power that typeclasses add to composition.
Come to think of it, you could use this to motivate typeclasses.

I think you could build *just as good* an introductory Haskell
course on the post-FTP libraries as you could on the pre-FTP
libraries, but it would be a *different* course.

The current proposal feels qualitatively different.  For one
thing, the FTP approach *could* have been taken back in
Haskell 98, or even earlier, had someone happened to think
of it, because all the typeclass machinery was there to do the job.
And it would have been obviously *useful* back then: "hey, you
mean that if I define a Tree type just a few more lines of code
give me all these summarisation methods?  Cool, this is just as
good as OOP."  But the current change is mainly warranted by
the desire to handle unboxed types.  That's an "engineering"
issue: if you're trying to make Haskell go fast, even 'unknown
size integers that go wrong' (Int) isn't fast enough, 'unknown
size integers that violate the all-values-are-the-same-size
assumption behind polymorphism' (Int#) are what you want.
This is not a problem in an introductory class, where you would
normally be telling people to use Integer because they have
enough problems without the weirdness of fixed-size integers.