Friday, February 23, 2007

Haskell A Superset Of OOP?

If this is accurate, it's pretty remarkable. It comes from a blog post detailing an implementation of Lisp written in Haskell:

Traditional object oriented languages let us abstract ourselves from writing [if-then-else] switches and take the task upon themselves freeing us up to do more important work. Haskell does the same thing, however, it doesn't limit the abstraction to types - we can get the compiler to write such switches based on any component we're interested in abstracting! We can, for example, get the compiler to write code for us that will cause the runtime to only execute a particular function if the first argument is equal to five, or if the second element in a list is equal to three. We could do that in traditional languages with if statements and switches but Haskell does this for us in a much more elegant and expressive way. After all, why are we only allowed to create virtual functions based on the type of the object they belong to? Why can't we define "virtuality" based on the type (or value) of the function's third argument, for example? Interestingly, this is one of the reasons why Haskell isn't object oriented - it's functions don't need to belong to objects because the compiler and the runtime system allow us to abstract over any argument's type and structure (contrast that to being able to abstract only over an implicit this)!

The implication is that from a Haskell perspective, an object-oriented language is one which comes with one (and only one) simple mechanism for abstraction that consists entirely of an embedded this flag variable which every piece of data is guaranteed to have by default. If I understand correctly, Haskell's abstraction mechanism operates as a superset of this paradigm, because it can abstract over other things as well as the implicit flag variable.

Pretty interesting. If I've understood, then I totally understand the appeal of Haskell as well, because that's pretty powerful. The only thing I don't get is why Haskell would be preferred over Scheme or Common Lisp; surely, if Language A wins because Language A's functionality is a superset of Language B's, then absurdly powerful languages are the best. I'm assuming there's something which Haskell is best for, which Lisp cannot do, or can't do as eloquently, and that this is why Haskell exists in the first place. But I'm not sure.


  1. Haskell isn't a superset of OOP, it simply has more methods of dispatch than OOP, so does Lisp. Neither of them are OO, so you can't compare them by counting methods of dispatch. CLOS isn't OO, I don't care what anyone says.

    It's an old argument, but imho, if you aren't dispatching on the "this" pointer, you aren't doing OO. That's not a value judgment on dispatching on other things, like all the argument types, or predicates on their values.

    OO is about more than how many things you can dispatch on, it's about who's in charge, who owns the data. If you can dispatch on any argument, then no argument owns the method, and you can't put the method into the class of any type.

    This leaves you with generic methods and little if any encapsulation, which while cool, isn't OO and doesn't give you the main thing OO gives you, the ability to reason about code by anthropomorphizing the objects and using your brains natural social abilities to keep track of who does what and why.

    I'm not making any value judgments on which method is better, but I think it's important to understand that single dispatch is rather fundamental to the nature of object oriented programming. No attempt at adding multiple dispatch to OO that I've seen, still maintains that OO feel.

    Multiple dispatch is way cool, but as soon as you start using it, the function becomes more important than the object. You're no longer working with intelligent objects collaborating to accomplish work(like people do), rather you've switched to working in an intelligent environment for dumb objects, where the environment the objects are collaborating in is actually doing all the work.

    Multiple dispatch may be able to do everything and more than OOP does, but it doesn't, and likely won't ever feel like OOP, because its focus isn't on the object as the collaborating entity. There's nothing remaining to anthropomorphize, so reasoning about the probable outcome of an operation can no longer play on your brains natural social skills the way it can with single dispatch. Whether this is good or bad is a personal judgment, but it's something to note none the less.

  2. The thing that came to mind as I read this description was specialized function templates in C++. I believe you can do the same thing with them. For example, you can make the program call a specific overloaded function if the type of the first argument is a string (or any type you specify for it). You can certainly have it choose an overloaded function based on the number of parameters. I forget, but you may even be able to have it choose an overloaded function based on the value of a parameter. The overloaded function doesn't have to be associated with an object to do this, either, though you can do all of this with class methods. Maybe I'm missing the point here, but this doesn't sound like something that is special about Haskell. Yes, it's a form of abstraction for function dispatch, but other languages have similar features.

    Maybe what this was contrasting was Haskell vs. Ruby and Smalltalk, since Ruby and Smalltalk are dynamicly typed languages and so there's limited dispatch rules based on type. The only type that can be discerned by the VM is the object itself. Messages/method calls can be overloaded based on the number of parameters in them, but not on the types of the parameters. This is something I've reflected on WRT Smalltalk. You don't have as many rules to play with for method dispatch. OO's answer for this is interfaces--abstraction of the type. If multiple types are going to be passed into a method, encapsulate them inside of classes with a common interface, and deal with them that way.


Note: Only a member of this blog may post a comment.