sum :: (Num a) => [a] -> a
Which means: for any a which is a number, sum can be used to add up a list of as.
However, going back to the C# example, you'll note we said IEnumerable<T>, not List<T>. In C#, the container is general, but in Haskell it's specific. And since IEnumerable is an interface, this actually means "any type that is enumerable". Haskell has an analogue of IEnumerable called Foldable.
So, what we _really_ wanted sum to say was "sum is a function that, for any container f that is foldable, for any type a that is a number, takes an f of a and gives you an a".
sum :: (Foldable f, Num a) => f a -> a
This is the AMP style version of sum. Some people hate it, I love it.
However, there's another piece of background to this that the email doesn't mention: the Haskell Platform is under attack itself. There's a new solution called stack which is, to my mind, easier to use and less likely to bite you with version conflicts. And whether HP should continue to be the "default" recommended way of starting with Haskell is, at best, controversial.
In short: there's plenty of people who won't miss his work on Haskell Platform, but losing Mark himself is a loss.
A thing about Foldable is that you can fold over it (obviously) but you can't necessarily map over it because in Haskell the general map (fmap of the Functor typeclass) has the law that `map (f1.f2) enum == ((map f1) . (map f2)) enum` but for example for Set this law won't hold because the intermediate set might drop elements identical elements that would not have been identical would the f1.f2 been applied in direct succession. See [0] for an example. Why fmap has this law I don't know, but Functor is super fundamental in Haskell's types so you can bet it's there for a good reason.
Note that this Foldable-Traversable-Functor introduction into Prelude is not complete yet. For example the map in prelude is: `map :: (a -> b) -> [a] -> [b]`. If this movement continues it will possibly be `map :: (Functor f) => (a -> b) -> f a -> f b`. People are super scared of the name Functor, so I think that's why it's not been adopted yet. It should possibly be renamed to Container or Mappable to be more in line with what general developers expect.
Would prelude's map be made equal to fmap however, it would make prelude super powerful. It would suddenly work on any Functor type, not just List.
[0] https://www.fpcomplete.com/user/chad/snippets/random-code-sn...
p.s.: if you don't grok typeclass, call it classclass instead, i.e. class of classes. And then think about how C#'s Interface also defines a class of classes.
The law is the only law of fmap, which is the "structure preserving law". It means that if you apply a function to each element of the structure, you cannot change the shape of the structure.
This structure preserving property means you can safely apply any function (even ones you don't know what they do) and you can be safe you're not losing information beyond what the function takes away.
> It should possibly be renamed to Container or Mappable to be more in line with what general developers expect.
Mappable would be a truthful name. Container is not a good name because far from all Functors are containers. You can map over a lot of things (I/O actions, functions among others) which are not intuitively "containers", unless you revise your intuition of "container" to mean "mappable". :)
The good thing about calling it for what it is – Functor – is an argument commonly lifted by Edward Kmett: when you're honest about what you're dealing with, you instantly give people access to 80 years of collective knowledge about the thing.
[0] https://wiki.haskell.org/Foldable_Traversable_In_Prelude
In practice, I think #2 was a fairly uncommon case, and the fixes were trivial and backwards compatible, so the cost was deemed pretty acceptable. #1 is a point of debate, because 'beginner' needs context (perhaps experienced programmers that are Haskell beginners would get over it quickly, but non-programmers would be substantially more confused, etc). Unfortunately I don't think we have a lot of truly empirical evidence on #1.
- I can fold a list, but what about other types? Which of the similarly or identically named functions dispersed among a bewildering number of library modules is the right one? Are they any different?
- I can fold a Foldable? What is it? Let's find a tutorial about Foldable. Ooh, nice! That takes care of folding anything that can be folded! If I'm not folding a list I only need to find where the relevant Foldable instance is (very easy) or to write one myself (reasonably easy).
find :: (a -> Bool) -> [a] -> Maybe a
find :: Foldable t => (a -> Bool) -> t a -> Maybe a
The obvious beginner question looking at this code is "what's `t a`?", and now you have to explain type classes to someone who just wanted to find an element in a list.There's a list of arguments against FTP compiled on the Haskell wiki: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List
If someone want to compute lists, it could use a spreadsheet program. It's just better!
Instead of explaining that [a] is a List of a's, and then explaining what a list is, you explain that t is a container that is foldable which contains a's.
Does he really need to know the exact details of what a typeclass is?
I'm guessing you have experience with languages that have generic types. The issue with the new Haskell prelude is that not only do you have to grok generic typing in order to write the most basic of Hello World introductory programs, you also have to be able to make sense of the Haddock docs. And that now requires knowledge of the type class syntax as well as basic understanding of generic programming. Whereas previously you could have softened the blow by teaching the special case of "[a] means a collection of a" first, and ramping up to more precise definitions later.
Overall, I'm supportive of the FTP initiative. But I can't shake the thought that the vast majority of people who voted for FTP have long passed the point where they can fully understand the downsides of the change for others.
It was at that time thought that by keeping prelude simple (pure FP 101 style) it was more accessible to new programmers.
Apparently that mindset was reconsidered recently.
So the big downside is that now if you teach Haskell and want to use Prelude, you'll be forced to almost immediately teach typeclasses.
In my opinion that's not a bad thing at all. Typeclasses put Haskell (and FP in general) right in league with big feature languages like C# and Java. All big features of Haskell are implemented using typeclasses (such as the reputable IO monad). Not teaching that as a fundamental feature right at the beginning only makes the next hurdle of the more category theory heavy advanced features of Haskell that much higher.
This just appears to be a decision of an individual to stick to what they think is the best platform/version for them. Since the individual was also the Release manager, seems like stepping aside was the logical thing to do if they do not prefer the latest version of the language.
https://www.reddit.com/r/haskell/search?q=foldable+traversab...
[0] https://wiki.haskell.org/Foldable_Traversable_In_Prelude