Andreas Rossberg: Andreas R. wrote:

"dynamic binding" is just the OOO way of saying "calling a first-class function").

Let me presume that dynamic binding was meant here in the sense of late binding, in the sense of subtyping polymorphism. At least, the given shapes example strongly suggested that. If so, I can't fully parse your reply in this context. Please elaborate. (First-class function seems to refer to currying or what?) (Did you miss a "polymorphic" before function? That would explain it. But then again, note, *first-class polymorphism* comes at the price of extra types just as the ugly ex. polymorphism trick. (This is of course just the same trick, indeed.) As we argue in Section 5.6 of the OOHaskell draft, current version, this does really not scale!) Andreas R. wrote:

In typical functional programming style, you need the general thing only rarely.

My impression is that the reason for not wanting (some do want however) true dynamic binding in Haskell relates more to the fact that we willingly make closed world assumptions about the cases to dispatch one. Where the C++ programmer defines classes, we are often just fine to define *one* datatype with n constructors (corresponding to n classes). In such a case, we have an easy time (except when we want case n+1 without recompilation). Using this "idea", late binding degenerates to pattern matching, which is the value-level variation on VMT dispatch. (And for the rare cases, where we want to become polymorphic with an open world, we seem to be willing to sacrifice type inference and we engage into existential polymorphism / first-class polymorphism.) And then of course with normal Haskell type classes we can nicely simulate *interface* polymorphism (again modulo the lack of type inference for subtyping polymorphism). So pre-OOHaskell doesn't miss a lot ;-) Ralf