[Haskell] Dynamic binding

[Ralf Lammel]

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