Stealing language features for fun and profit in Ruby

Hi all, I haven't used Ruby much yet, but I was happy to see this entertaining article about how to enable some language features common in Haskell, ML, Lisp and others (Pattern-matching, S-expressions).

If It's not Nailed Down, Steal it

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

First thing I read:

Pattern matching is a relatively rare language feature found in Standard ML, OCaml, Haskell, Common Lisp (CLOS), and a handful of others. It’s a form of multiple dispatch, so pattern matching functions run different code when called with different arguments. Pattern Matching lets you do this dispatch based on type, value, and even internal structure of the function’s arguments.

Umm... no. The only language here I'm not familiar with is Common Lisp. This statement is wildly inaccurate when applied to the others. Pattern matching does not allow for dispatch on type, and it's a relatively simple branching mechanism compared to multiple dispatch.

The authors never tried to run their Haskell definition of the fibonacci function. It diverges on all inputs other than 0 and 1, due to misplaced parentheses.

In Common Lisp pattern

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.

Pattern Matching is orthogonal to Multiple Dispatch

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.

Thanks for the feedback

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!



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.


In Ruby, the class Integer is actually an instance of class Class...

This is off-topic, but I am not familiar with Ruby. What does the above mean??? Does he mean subclass instead of instance? Is the superclass really, really named Class?

Stems from smalltalk

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

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

No, not subclass, he means instance

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 =

LtU comes to the rescue

The behavior of Behavior explains it for Smalltalk.