Type classes are just post-hoc interfaces, so you're no longer limited
to a declaration-time hierarchy.
The real question is inheritance. In what ways is inheritance useful?
From what I can see, it's most useful application are default
implementations of methods. But this can be provided by type classes
as well. Subtyping too.
So type classes are strictly more general than inheritance and
interfaces. Only downcasting/upcasting isn't provided by default, but
has been provided by libraries.
Do you have some argument or examples that contradict this conclusion?
What sort of scenarios push you toward a traditional OO structure?
Sandro
On 2011-04-01, at 19:06, "Jonathan S. Shapiro" <[email protected]> wrote:
While I have raised the topic on a couple of occasions, I have tried
very hard to resist introducing [single] inheritance into BitC. I've
avoided this for several reasons:
OO features are build around the "object" notion - which is to say:
"state plus interface". That in turn tends to drive us fairly hard
in the direction of a stateful language, which is a bias that I had
hoped to avoid.
The question of when to use inheritance and when to use type classes
seems challenging to answer. I wanted to avoid having confusingly
similar ideas in the initial language. If nothing else, I wanted to
avoid this for me. As a personal matter, OO idioms are very
familiar, and I found myself reaching for them at the wrong times.
Taken in combination with [1], this is a hazard to pure programming.
There are some typing issues around the notion of a "this" pointer
that I had hoped to dodge. I don't think these are terribly
difficult, but they exist, and it's one more thing to do.
Inheritance entails subtyping, which is problematic for inference.
The problem of const classes, and the resulting need to overload on
const-ness, was a nagging problem.
And yet, several issues seem to keep dragging me back in the
direction of single inheritance plus interfaces. The current
(incomplete) "capsule" mechanism is a constrained form of
inheritance. Closed type classes can also be seen as providing an
inheritance-like mechanism.
In the end, I think that there is a pragmatically overwhelming
reason to incorporate single inheritance and interfaces into BitC:
immediate utility. There are simply too many libraries out there
that we need to be able to use that are framed in terms of classical
OO.
I am certainly not proposing to eliminate type classes if we can
make them work pragmatically.
I also anticipate including the "interface" notion without the
implicit downcast capability.
Finally, I anticipate providing a means to generate interfaces as an
extended form of procedure object; effectively a collection of
procedures closed over the same state pointer (a very simple
extension of the current Interface idea that is conspicuously
missing in most languages).
Reactions and thoughts?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
