Faking it (even better)

Here's a spectacular paper by Oleg Kiselyov and Chung-chieh Shan which describes a method of faking dependent types in Haskell using type classes.

McBride mentions that, with all the tricks, the programmer still must decide if data belong in compile-time or run-time terms. "The barrier represented by :: has not been broken, nor is it likely to be in the near future." If our reflect and especially reify functions have not broken the barrier, they at least dug a tunnel underneath.

(Mentioned yesterday by Dave Menendez in the Apple Flunks... thread, but I thought the paper merited a discussion of its own)

Comment viewing options

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

Objects in Haskell

If you define objects to be data structures with collections of behaviors, I'm thinking that you could use the techniques in the paper to allow object oriented programming in Haskell.

why would you do that?

Is there anything that the "object oriented" paradigm can do that Haskell can't do? What exactly is Haskell missing? In some senses of the word, Haskell is already object oriented: it has ad-hoc polymorphism, encapsulation and user-defined datatypes; what more do you need? (besides dynamic typing...)


you can't really do independently extensible inclusion polymorhism, i.e. extend a type with a new case without having to touch any of the original code.

Haskell and objects

Greg Buchholz wrote: "I'm thinking that you could use the techniques in the paper to allow object oriented programming in Haskell."

That is the topic of the upcoming paper.

LittleDan wrote: "why would you do that?"

For example, to emulate the following OCaml function:

# let foo v = v#field_a;;
val foo : < field_a : 'a; .. > -> 'a = <fun>
That function takes any object which has the field named field_a and returns the value of that field, whatever it may be -- and whatever type it may be. Please note the inferred type. The function foo can be applied to objects that are in no subclassing relation to each other and do not belong to the same hierarchy. They merely need to have a field named field_a. It is possible to emulate this behavior in Haskell.

Please see also: Keyword arguments http://www.haskell.org/pipermail/haskell/2004-August/014416.html