Just so we're all on the same page, here is the notion of interfaces that I plan to implement for BitC:
An interface type consists of a set of named method signatures. Each method has some set of argument types 'a ... 'z and a result type 'result. This describes the "outer" perspective on an interface. The "inner" view of the interface is that an interface object contains an existentially encapsulating state pointer having type 'state, and a vTable pointer. The vTable is a table of procedure references. For each method named in the interface type declaration having type 'a...'z -> 'result, there is a corresponding implementation function having type 'state 'a ... 'z -> 'result. Calling a method at an interface has the effect of calling the implementing procedure with the additional 'state argument. Interface construction proceeds in the usual way for value constructors generally. The first argument to the constructor has type 'state, and the remaining arguments are the implementing procedures. The type constructor differs from the value constructor in that it omits the 'state type argument. So that's the core of it. It is unclear to me whether it is useful to add an "implements" clause to struct/union declarations. It seems like potentially useful sugaring, but I think it needs a usage experiment. Regarding syntactic support for "X as Y", I think that is determined by a two variable type class Castable. Some instances of this type class are implicitly populated by the compiler in the same way that CopyCompatible gets populated. So then we have the inheritance discussion... shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
