xi

http://www.haskell.org/onlinereport/decls.html#sect4.3.4

In my opinion, though it wasn't me you asked, it's an ugly workaround for Haskell's lack of proper coercion rules.

I love how you, in the same sentence, managed to put in doubt credibility of the upvoters and downplay the issue in hand.

To answer your question: yes, I actually read the article. Why I upvoted it? Haskell's way of wrapping integer literals with implicit `fromInteger` seems to be a clever hack that alleviates some pain when dealing with basic arithmetics, but I always wondered what kind of unexpected problems it may cause. I got an answer in this article.

Haskell's not like other languages, where you have to build up massive unreadable piles of code to get anything done.

That's fanboyism. I understand you feel offended by the OP's post, but it is not a good satire unless it offends somebody, and IMO, the article is excellent in summarizing attitudes of some members of the Haskell community. ;)

IMO, it proves exactly the opposite; a person could never say it unless they at least tried to write some Haskell code.

http://python-history.blogspot.com/2009/02/early-language-de...

In Python, you could limit generic dispatch to argument type only without losing generality since you could override the `isinstance` operator. For instance, you could define a `const()` type so that `isinstance(x, const(100))` is true if and only if `x == 100`. Then your example could be written in Python as:

  foo = generic()

  foo.when(const(0))
  def foo_0(x): print "passed in zero"
  foo.when(const(100))
  def foo_100(x): print "passed in 100"
  foo.when(const(200))
  def foo_200(x): print "passed in 200"
  foo.when(int)
  def foo_default(x): print "passed in", x

1) multi-methods are declared outside the class definitions; it is important since it allows you to extend a class without directly modifying its definition or implementation.

2) virtual functions do dispatch by one argument (`this` in C++) while multi-methods could perform dispatch by an arbitrary number of arguments.

That said, I don't like this implementation that much since it does not respect class inheritance. Suppose you defined a MultiMethod with two registered implementations, for class A and class B, where B is inherited from A. Then the result of the multi-method call with an object of type B is undefined. A proper multi-method would call the most specific implementation in this case.

dim(U+V+W)<= dim(U)+dim(V)+dim(W) - dim(UV)-dim(UW)-dim(VW) + dim(UVW).

So the result is weakened, but not entirely lost.