Actually, I also think that Haskell will not become mainstream. As a matter of fact, one of the main things I do not like about Haskell is that the type class mechanism makes too many things implicit and that it allows too much overloading. It seems that it is sometimes hard to understand what a code fragment does by just looking at the fragment. By contrast, OCaml code is much easier to understand.
But these are not so much syntactic issues. It always seemed to me that people are actually drawn to Haskell's syntax.
> It always seemed to me that people are actually drawn to Haskell's syntax.
Totally anecdotal, but this is really not the case for me. I have only dabbled in Haskell, and never really used it for a project from end-to-end, but have used Standard ML quite a bit in the last few months to write a lexical analyzer generator [0] and just recently spent a weekend and a half using OCaml.
There are a number of Haskell features and general design that I think are better than the MLs. While modules and functors are quite cool, I think typeclasses end up being more practical. Standard ML gets a lot of little things right that I think OCaml gets flat out wrong (mutable strings, throwing exceptions instead of returning 'a option), but Haskell seems to take it further, with a standard library that I can only describe as very tasteful. This is just my impression after reading half of Real World Haskell and doing a lot of dabbling but not a lot of real work, so I'm sure it's incomplete.
Haskell's syntax IS nicer than Standard ML's and OCaml's, but that is the least important thing IMHO. If there were an ML (strict, impure) with typeclasses and with as taseful design as Haskell at the edges, I would probably use that over Haskell, even if the syntax was ugly(ier). As it stands, I'm inclined to eventually switch to using Haskell, and just figure out how to deal with the other bits of it (laziness, purity), just so I can use typeclasses and the well-designed bits.
[0] In case you doubt how much ML I've written, the repo is on GitHub
No, I haven't, but does it add more to ML than a bunch of syntax changes? It looks like an attempt to make ML more palatable to programmers familiar with C and Java. I skimmed the docs on that site and saw that it does have ML-style modules and functors, but does it also include something like typeclasses? I thought combining the two was still almost an open research question, although tbh I haven't slogged through this paper yet: http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf
To be completely honest, I'm a little skeptical given that the first page in the "Mythryl for SML programmers" highlights adding special-cases to the front-end to support printf: http://www.mythryl.org/my-Mythryl_printf.html I don't really miss printf in SML, although if I wanted it I think I would rather reach for this kind of type hackery instead: http://mlton.org/Printf
Yes, it's verbose, but verbosity also adds information that may be useful (although + is probably not a good example for this). With 'easier to understand' I mean that when looking at a bit of code I can tell what it does without having to know much about the context (typing, overloading). I did not mean to say that the code is prettier. Haskell code tends to be very pretty.
It's probably difficult to strike the right balance between too little and too much overloading. Maybe OCaml does not allow enough overloading. For my taste typical Haskell code uses too much. But that's a matter of taste, I suppose.
>when looking at a bit of code I can tell what it does without having to know much about the context
How do type classes make that harder? You either need to understand what "foo" does, or you need to understand what "fooForThisType" does. What's hard about the former?
You need to know the type. I wouldn't want to say that makes reading code "hard", but it means that you need more context in order to understand the code. (Imagine, for example, that you're trying to understand a patch, where not all types are obvious).
You only need more context in order to know where to look to understand the code. If you don't know what foo does, you have to go look at the definition of foo. If foo is obvious or common, then you don't care which instance's version of foo is being called. To a person reading the code, + is + regardless of whether it is adding ints or floats. If you are looking at a patch and don't know what a function does, then you need to go look at the actual code. In which case, the types are now obvious (or can be given to you by the compiler if they are not obvious).
Are there alternative approaches I am not aware of? All I can see is encode the type in the name of the function (fmapList, fmapMaybe, fMapVector, etc), or forcing the functions to all be in separate namespaces and have to qualify them (List.fmap, Maybe.fmap, etc). Both seem much worse than typeclasses.
But these are not so much syntactic issues. It always seemed to me that people are actually drawn to Haskell's syntax.