On Mon, Mar 22, 2010 at 8:01 AM, Rick Richardson
<[email protected]> wrote:
> So so summarize, I vote yes for typeclasses, no for inheritance. Just my
> two cents.
It might be useful to try to pin down what the difference is between
inheritance-style OO and type clases.
Type classes inherently provide inheritance. Any time you build a type
class (B 'a 'b), you can say "in order to be in (B 'a 'b), you must
also be in that other tpe class (A 'a 'b)". This offers both single
and multiple inheritance of traits, but not of implementation.
Because BitC implements n-ary type classes, a type class cannot have
methods. None of the types in the type class relation are "primary",
so there is no obvious type to attach the method to. When we implement
structure polymorphism, this will become possible. Structural
polymorphism will give us a new constraint:
(has-field 'a FIELD-NAME 'field-type)
and the legal field types here would presumably include ('a method 'b -> 'c).
At the moment, we do not permit implicit cast, but we do handle some
forms of implicit conversion (mainly around permissions) at points of
assignment and binding. I provisionally think that we could do the
signature subsumption test at method bindings, though I'm concerned
about inferred subtyping (admittedly, I may be over-concerned).
One step on the path to inheritance would be to allow a type class to
refine the requirements for an old one. For example, we could allow a
method requirement in a sub-typeclass to be a refinement of one
expressed in a super-typeclass.
The missing link, then, is to associate objects with the type class.
To what extent does the combination of DEFOBJECT and DEFTYPECLASS
currently give us this? Could the whole problem be as simple as single
inheritance over DEFOBJECT?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
