Lambda the Ultimate

In Common Lisp pattern matching can and often do dispatch on types. I dont think its fair to say that Standard ML, OCaml and Haskell dont have pattern matching just because they doesn't have as expressive polytypic pattern matching as in dynamic languages like Common Lisp and Ruby.

ML certainly has pattern matching, what I meant to say was that the characterization of pattern matching is wrong. Pattern matching, like multiple dispatch, is a branching mechanism. However, pattern matching is simpler and tends to be more efficient.

Glasgow Haskell's multi-parameter type classes provide polymorphic multimethods. Combine this with existential types and you have fully dynamic multiple dispatch. This facility is quite different from pattern matching.

Moreover, pattern matching macros are available for Common Lisp and Scheme, but neither language defines a standard pattern matching facility.

Author here.

Doh. Thanks for catching my Haskell typo. I'll ping my editor and see if we can change it.

I'm not really an ML expert, my only experience was during a year or so in school. Pattern matching ML functions can branch (and destructure) based on the datatypes they are called with. Is there a reason you don't consider that dispatch based on type?

Mind you, I'm not arguing. I trust the collective wisdom of LTU. In fact, I had originally thought about pinging some of the LTU editors before this went live, since I was worried my terminology might not be precise enough... guess I should have done that!

Is your critique of the multiple dispatch versus pattern matching issue that pattern matching can also be used in other situations, ala Case statements? I've often heard the term "pattern matching functions" used interchangeably with "pattern matching." Perhaps I used a too general word? Or is there a deeper misunderstanding on my part?

I'd be thrilled if the LTU community could help me refactor that paragraph into something more accurate!

Topher

Is there a reason you don't consider that dispatch based on type?

Pattern matching in Haskell, SML, etc., is branching on the data constructor, not the data type. Consider:

data Either a b = Left a | Right b

process :: (a -> c) -> (b -> c) -> (Either a b) -> c
process l r (Left a) = l a
process l r (Right b) = r b

process pattern matches the data constructor of the value it is given as its third argument, but each and every one of these values will be of type Either a b; it is dispatching on the tag of the value, not its type which is invariant (modulo type variables).

Oh, I never realized that. I'd always assumed that if I also wanted to branch the process function on another datatype as well, I could do that, resulting in the type of the parameter that varies (for, say, a map function) being something like (Tree a | List a) -- made up syntax where | means "or". I guess it's been long since I last used SML.

This all probably reflects a poor understanding of type systems on my part. Time to start thinking about grad school I suppose! =)

Thanks for taking the time to walk me through that. I'm off to sleep now, but I'll take a crack at rewriting that paragraph tomorrow.

[R]esulting in the type of the parameter that varies (for, say, a map function) being something like (Tree a | List a) -- made up syntax where | means "or".

type TreeOrList a = Either (Tree a) (List a)

process (Left v) = processTree v
process (Right v) = processList v

Polymorphism or the variety you seem to be thinking of is accomplished with type classes in Haskell (vaguely similar to interfaces from Java) or, IIUC, structures in ML.

Converting to a string might be a good example. In Java, toString is inherited from Object and the correct implementation for the object being sent the message is called using the usual method. In Haskell, we can define an instance of the function show that can convert our specific data type into a string. When show is called on a value, the implementation of show for that data-type is called (using type classes which are usually implemented by passing around a dictionary of function implementations when the type can't be statically determined).

Where Class is a subclass of Class which is subclass of Class...

I agree that it should stem from Smalltalk, but some generic class (i.e. Integer) is actually an instance of Class, which is an instance of Class etc
I think that in Smalltalk, Class is an instance of MetaClass which is an instance of MetaClass...

The class hierarchy is much more messy in both languages I think.

I think in Smaltalk an integer is an instance of the class Integer, which is an instance of Integer Class, which is an instance of MetaClass, which is an instance of MetaClass Class, which is an instance of MetaClass. Not to mention all the superclasses of these classes.

Hierarchy of Smalltalk classes

Classes inherit from Object in Ruby. Classes also happen to be instances of the class named "Class". e.g. this is valid ruby code:

Integer = Class.new

The behavior of Behavior explains it for Smalltalk.