On Wed, Feb 25, 2015 at 8:22 AM, Keean Schupke <[email protected]> wrote:
> By capsules you mean existential types? This is currently my preferred > method for runtime polymorphism, implemented using virtual functions on the > type-class. > > I would be interested to know the problems with this as I like it as a > solution. > I'm referring specifically to the BitC v0 mechanism, which implements a form of existential encapsulation. Conceptually, make-capsule arranges for several lambdas to be closed over a common (shared) closure record. From an implementation perspective it forms a (vTable reference, closureRecord reference) pair. The result is an object having methods. The construction mechanism doesn't really provide for subclassing or inheritance. The most obvious problem is that make-closure is an allocating operation, and we need to be able to use existential encapsulation in some places where allocation is not permitted. I suppose we could have it return an unboxed pair. The next most obvious problem is that too much indirection is required when a capsule method is called. The third obvious problem is that *sometimes* you want a "translucent" existential, in the sense that you want to be able to dynamically cast back to the original record type. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
