Hi Shapiro, Your explanation of typeclasses reminds me of how generics are handled in CLR VMs.
The naive approach to support generics by a CLR VM is to expand every instantiation and produce native code for all variations. This is far from optimal as the generated bloat usually interacts pretty bad with the icache. What the VMs support [1] is sharing code for all reference types, which expands to pretty much the same thing. For valuetypes this sharing is non-trivial so no VM does it. >From my narrow understanding of typeclasses, they can be seen as interfaces that don't need to be explicitly implemented by the target types. So the problem of sharing code for typeclasses is then pretty much the same as for sharing for generics types with bounds (restrictions on the type arguments) [2]. The main issue we had within mono was carrying runtime information around to make introspection works. I don't know how much introspection/reflection support BitC has, but it would be nice if you could explain how do you plan on tackle on these issues. BTW, I think BitC would map very well on top of the CLR given it had interface injection support. [1] Well, mono, which is the VM I know about. But microsoft's VM have a similar approach. [2] The issue of interface injection is orthogonal to this discussion. On Fri, Nov 14, 2008 at 12:53 AM, Jonathan S. Shapiro <[EMAIL PROTECTED]>wrote: > Recently rys asked over on the Lambda The Ultimate blog: > > I understand objects and v-tables, which sound like C++, but I don't > understand typeclasses and polyinstantiation, which sound like the sort of > algebraic approach to languages I always ignore. Are they as abstract as > they sound? Or are details as concrete as v-tables? Can typeclasses be made > a space efficient as v-tables? > > This note is an attempt to answer that question. If you've been tracking > the list, you may find it repetitive. > > C++ objects end up tying three things together inseparably: > > 1. Data structure layout. Derived classes necessarily inherit the > members of their parents > 2. Interfaces. The virtual function mechanism is basically the only way > to state a common interface in C++. > 3. Subtyping. > > The first two ideas are important. The last may or may not be. The key > point is that there is no reason to tie interfaces and structure extension > together. A common interface means, simply, that two objects implement the > same protocol. It does not require v-tables at all. > > The Java "Interface" notion is often closer to what you want. It states a > collection of methods, and *any* object that implements all of those > methods can be referenced via that interface. This is exactly what type > classes do. > > While type classes are most commonly implemented using "dictionaries", > which are similar to v-tables, the details of assembling dictionaries are a > good bit more complex than the details for v-tables. Where v-tables only > need to consider a single object, dictionaries sometimes need to consider > interactions between multiple types, and this can create a requirement to > fabricate dictionaries dynamically (something that BitC wanted to avoid). > What we have chosen to do in BitC instead is to move all of the resolution > of dictionaries into the polyinstantiator, which basically acts like > template instantiation in C++. > > But in contrast to template instantiation, we know quite a lot about the > types being instantiated, and there are a number of ways to avoid doing > stupidly redundant instantiations. > > Either the dictionary approach or the instantiation approach is correct, > and either can implement the BitC semantics. At most, BitC will require that > an implementation must specify which technique it uses. The issue is that in > some applications, dynamic allocation of dictionaries would introduce a > requirement for garbage collection that we wish very much to avoid. > > BitC "objects" are doing something completely different from C++ objects, > which is why we will probably rename them "capsules". Capsules exist to do > type hiding, and that is about it. > > I'm not sure if this response adds to or reduces rys' confusion. Hopefully > he'll come out of lurker mode and tell us. > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
