Comparing the lists with == requires elements to be comparable (denoted as Eq a). Prelude> :t (==[]) (==[]) :: (Eq a) => [a] -> Bool For example, [sin] == [] won’t work, since you can’t compare functions. It might seem stupid, but the type system must judge type of an expression without looking at its … Read more
After having a look through the GHC manuals and around the Haskell wiki (especially the List instance page), I’ve got a better idea of how this works. Here’s a summary of what I’ve learned: Problem The Haskell Report defines an instance declaration like this: The type (T u1 … uk) must take the form of … Read more
I guess I’m one of the few people who have first hand experience of why it was hard, since I implemented it in hbc when there was no prior art. So what was clear from the Wadler&Blott paper was that type checking was an extension of Hindley-Milner type checking and that at runtime you should … Read more
Ok, I had several discussions with other people before posting here because I wanted to get this right. They all showed me that all the problems I described boil down to the lack of polymorphic constraints. The simplest example of this problem is the MonadPlus class, defined as: class MonadPlus m where mzero :: m … Read more
The ListLike package seems to provide what you’re looking for. I’ve never understood why it isn’t more popular. ListLike aside, one reason this isn’t implemented in the Prelude is because it’s not possible to do so well without invoking some language extensions (multi-param type classes and fundeps or associated types). There are three sorts of … Read more
This is right. There is also another quite important reason for this behavior: You can think of Either a b as a computation, that may succeed and return b or fail with an error message a. (This is also, how the monad instance works). So it’s only natural, that the functor instance won’t touch the … Read more
My brief answer is: OO is not powerful enough to replace type classes. The most straightforward translation is to pass a dictionary of operations, as in one typical typeclass implementation. That is if typeclass Foo defines three methods, then define a class/record type named Foo, and then change functions of Foo a => yadda -> … Read more
It doesn’t work in scala 2.11 and earlier because Either is not a monad. Though there’s talk of right-biasing it, you can’t use it in a for-comprehension: you have to get a LeftProject or RightProjection, like below: for { foo <- Right[String,Int](1).right bar <- Left[String,Int](“nope”).right } yield (foo + bar) That returns Left(“nope”), by the … Read more
Overloading is typically the bugaboo of type-inferenced languages (at least when, like F#, the type system isn’t powerful enough to contain type-classes). There are a number of choices you have in F#: Use overloading on methods (members of a type), in which case overloading works much like as in other .Net languages (you can ad-hoc … Read more
Type and data type refer to exactly the same concept. The Haskell keywords type and data are different, though: data allows you to introduce a new algebraic data type, while type just makes a type synonym. See the Haskell wiki for details.