[Haskell-cafe] Re: [Haskell] Dynamic binding

[Ralf Lammel]

> Off-hand, I recall a paper by Martin Odersky and the Scala people
> discussing their approach to the Expression Problem,

So ...

http://icwww.epfl.ch/publications/documents/IC_TECH_REPORT_200433.pdf

... I guess 

The key innovative idea there is composition of mixins while replacing
formal superclasses of mixins by the actual base class for mixin
composition. 

I quote:

"In a mixin composition
A with B with C, class A acts as actual superclass of
mixins B and C, replacing the declared superclasses of B
and C. To maintain type soundness, A must be a subclass
of the declared superclasses of B and C. A super reference
in either B or C will refer to a member of class A. As
is the case for trait composition, Scala's mixin composition
is commutative in the mixins - A with B with C is
equivalent to A with C with B."

In OOHaskell,
you would parameterize in the superclass and that's it.
DISCLAIMER: we haven't tried this.
Thanks for the inspiration.

> and a related paper by Jacques Garrigue,
> where he proposes to solve it using OCaml's polymorphic variants.

I am not sure.
Is this referring to "Objective Label"? Which paper exactly?
 
> Hope this helps,

It's interesting
but I don't see how we make progress with the original 
(by now perhaps trivial) question regarding the transportation of
an OO design into Haskell. The shapes problem doesn't call for
Odersky's new contribution:

I quote:

"We add to this list the following criterion:
* Independent extensibility: It should be possible
to combine independently developed extensions so
that they can be used jointly [21]."
 
The shapes problem rather calls for silly subtyping polymorphism.
So we are beating a dead horse (or a red herring)
by detouring to Scala unless I don't get you were hinting at.

BTW, I just notice that
Oderksy's list of partial solutions isn't complete:
- Visitor combinators (Joost Visser) complementing Palsberg et al.
- Many forms of generic functional programming (Hinze etc.)
- Haskell type classes allow for extension in both type and processor
extension.

It's getting late here.
Ralf