On Tue, Mar 23, 2010 at 12:34 AM, Michal Suchanek <[email protected]>wrote:
> As I understand it there are structures which just include random > stuff and there are types which put requirements (specifically they > require methods to be present) on structures to which they can be > bound. > I think so, but I am not clear to parse your sentence. I would have said: - There are structures which include arbitrary fields and methods. These define both a (possibly parametric) struct type and a representation for the struct. [Methods on structs are syntactic sugar, but are relevant for matching purposes when DEFOBJECT is used.] - There are type variables that can be bound to these struct types at instantiation time. - There is a constraint system including a constraint (has-field 'a _field_name_ 'field-type) whose effect is to constrain the struct types that can legally be bound by a type variable. The other reading of what you say is that the constraints themselves are types. This is the point that I find confusing. I find the same point confusing in Bruno and Martin's work. By the way, I have invited Bruno to join the list. He currently is working on a paper deadline, but *may* decide to join us later. > There is some sense in merging or extending the types. If you want an > argument passed to your code to have the traits of multiple types you > can explicilty bind it to multiple types but then you end up with what > appears to be multiple objects while they are in fact multiple views > of the same object. > For value (unboxed) types this is tricky. > This can be resolved by adding the ability to merge types so that you > can bind all the required interfaces in one place. I would not try to > call this inheritance and I specifically don't see why this would be a > case for *single* inheritance. > In my opinion, BitC has sufficient encapsulation capabilities to do a perfectly good job at abstraction. The only reason to consider single inheritance at this point is interoperation with existing type systems such as CTS. > Single inheritance is very limited and since the types are something > that can be optimized away in the actual machine code and does not > require any storage of its own there is no need to resort to single > inheritance. Single inheritance is AFAIK a way to have inheritance in > place but avoid the issues of ordering storage for multiple ancestors, > especially if there is the same ancestor included multiple times, and > resolving the lookup order of methods. > Again, the goal here is to deal with CTS. CTS is limited to single inheritance, thus my focus on single inheritance. > If the types allowed inferring new methods based on the requirements > they put on the struct this would be a different matter as the > inferred methods could clash then and the problems with lookup order > would apply. > This is certainly an issue in the usual way of implementing single inheritance. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
