On 23 March 2010 17:44, Jonathan S. Shapiro <[email protected]> wrote: > 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.
Then ask where the types are. Are there in the structures? Certainly not. The structure has its own unique type and physical storage layout but multiple different structures can be bound to the same type variable so it's the type variable that corresponds to the type. I think that the fact that in C/C++ the type is bound to the physical layout of the structure is basis for lack of flexibility. > > 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. There are also systems with multiple inheritance but I don't really care. What I do care is that it can be expressed what the foreign functions accept and return. And they accept and return struct, not types. Types are for seamless working with these structs. Consider for example the palette entries for an index-color video mode. These can be in mutiple orders, most likely RGB or BGR. You can have multiple graphics drivers that work with differently ordered entries and the application can use all of them as type RGBpalette just fine because the type system hides the layout. The problem comes within the driver when it receives palette data in arbitrary order and it has to write it to the hardware in the correct order but at least when the data is returned from the driver this path is covered by the type abstraction. > >> >> 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. Again, I would say that the focus should be on representing what CTS accepts and returns, not its type system. If you went this route you would have to implement every possible type system to be compatible with multiple languages. You should be able to define the CTS types as structs and their ancestry as compatible types. The issue is again in the case you want to pass a parameter into CTS and it has to be a structure with a particular layout rather than an abstract type. > >> >> 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. Then don't do inheritance. Add the ability to merge the constraints constraint set C = constraint set A + constraint set B + additional constraint 1..n - there is no problem here, if a method is required multiple times it is just required. If you also allow inferred or as you call it non-virtual methods then allow renaming them when including another type. Thanks Michal _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
