I spent so long at university writing out GoF style stuff (I want to say crap) like the visitor pattern in java. Now I write ruby. Those are hours and days I will never get back. I remember thinking at the time, "Why am I doing this? Surely this is what computers are for?"

I guess it's all education in the end. At least now I appreciate the value of the tools I have.

Negative, the Visitor pattern cannot be naturally replaced with map and fmap. Read up on double dispatch at e.g.: http://en.wikipedia.org/wiki/Double_dispatch

But then neither of those problems exist in Common Lisp, as you have both first-order functions and multiple-dispatch in object model :).

Maybe not in Haskell, but Clojure's multimethods handle this just fine.

Haskell's type classes generalize further than multi methods do. You get dispatch based on any part of the type signature, not just the arguments.

Not further than Clojure's multimethods. They dispatch on the value of an arbitrary function you write. This can be anything; it's not even restricted to types. Couple this with Clojure's ad hoc hierarchy system and even Haskell's types seem limited by comparison.

Can you implement the Read class in Clojure?

  class Read r where read :: String -> r

(Let's ignore parse errors for our purposes here)

Haskell supports return-type polymorphism. Clojure, being dynamically typed, cannot in general support this kind of overloading.

Good point, though Clojure's extensible reader takes care of most of the use for this.

I think it's a trade-off though. Can Haskell dispatch on a value rather than a type?

Note that this feature is far from being useful only for class Read.

The Monad class actually depends on it too:

  class Monad m where
    (>>=) :: m a -> (a -> m b) -> m b
    return :: a -> m a

The type of "return" can only be expressed with return-type polymorphism.

This means you cannot really implement Haskell-like monads with dynamic typing. You have to implement them in a less general way.

As for dispatching on runtime values, that is ordinary pattern matching:

  f (RuntimeValue1 x y) = ... case 1 ...
  f (RuntimeValue2 x y) = ... case 2 ...

>This means you cannot really implement Haskell-like monads with dynamic typing.

Ahh, yeah I've heard this before. It totally slipped my mind.

>As for dispatching on runtime values, that is ordinary pattern matching

Can you extend the patterns of a function at runtime (or even across modules)?

No, you can't write a function spread across modules depending on the value of its input, short of implementing a dispatch system.

that means that the visitor pattern can be replaced with multiple dispatch (true) but neither map nor fmap imply that (and in fact many languages have the latter but not the former)

Clojure has both map and multimethods. It's trivial to map over a collection and dispatch to a different implementation for every element in the collection. With multiple collections, this extends to multiple dispatch over the corresponding elements in each collection.

I will rephrase myself: the original statement is

    you can do V with F

to which the reply was

    no, you can't do V with F

and the subsequent reply was

    but you can do V with M

and I pointed out that F does not imply V. Your current reply is

   Clojure has both F and M and can do V

which is obvious, since M implies V already, but still unrelated to what F can do.

Many kinds of visitor pattern are just fmap (better call it Functor).

Here is the good explanation: http://www.haskell.org/pipermail/haskell-cafe/2009-June/0623... Haskell people are good at math

Double-dispatch seems to be equivalent to Haskell's pattern matching.

Since Haskell does not have sub-typing, everything has the same runtime type. However, you can easily combine different types into a single algebraic data type and then dispatch by pattern matching against that type.

This probably isn't exactly the same as double-dispatch in other languages, but it seems to be very similar and to serve the same purpose.

Not map; pattern-matching is what replaces Visitor.

Visitor was about multiple dispatch, which multimethods, type-classes and pattern-matching can all handle.

However, it was also about iterating an entire data structure (in the GoF example, a document hierarchy).

This creates confusion as some emphasize the former (multimethods! pattern matching!) and some emphasize the latter (fmap! map!).

Implementation details are the least valuable part design patterns. Implementing a visitor via map doesn't some how make it not a visitor. You still have to have some way of referring to what is going on when you do visitor like things.