On 23/03/2010 7:15 PM, Jonathan S. Shapiro wrote:
> If you start from a C++ background, it seems very natural to ask:
> shouldn't classes subsume structures/records, and it seems natural
> that the answer to this should "obviously" be yes. O-classes do not
> have this subsumption property, and in consequence, they will carry a
> high runtime performance overhead. An O-class defines a dictionary, so
> in general its "methods" must be invoked through a dictionary with the
> associated costs of that invocation. More problematic, an O-class has
> no fields, so simple getters and setters have prohibitive cost.
What kinds of getters and setters are you considering? It seems that if
you're looking at getters and setters, you already have a concrete class
*instance* in mind, not an abstract class/interface as described in the
paper, in which case you should just match on the constructor(s) of
interest and extract the field you want.
Granted, the paper restricts pattern matching, but you could introduce
an "open" pattern match, of a type covered in other papers ("open
datatypes and open functions").
A field shared by all instances of a class X seems unlikely, since in
all likelihood you'd factor it out into a separate class Y which
encloses a reference to class X now lacking the field.
If for some reason there is indeed a field shared by all instances of a
class, you could introduce a special type of method, a
selector/accessor, which in the method dictionary is just an offset into
the instance record instead of a function pointer. This might be what
you described here:
> This brings me to the following question: why not let classes have
> fields just as structures do? Then divide "methods" into BitC-style
> methods (which are mere syntactic sugar) and overridable methods
> (which are O-class methods). Offhand, I don't see any reason why the
> resulting classes would fail to subsume typeclasses just as O-classes
> do.
I'm not convinced that you would have all of these shared fields, and so
the need for accessors is unclear to me. Unless you're also trying to
unify record calculi with GADTs and type classes? That sounds neat, but
ambitious. :-)
Sandro
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
