On Sun, Jun 17, 2012 at 9:17 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Sat, Jun 16, 2012 at 7:49 PM, Matt Rice <[email protected]> wrote: >> >> On Sat, Jun 16, 2012 at 2:11 PM, Jonathan S. Shapiro <[email protected]> >> wrote: > > 2. I suppose we could make the type existential, relying on whole-program > compilation to expand it. But actually that doesn't quite work, because we > need to do type checking when the object gets passed back into the library. > So what we need here is a notion of a [partially] opaque type. If we had > that, we could make this work for whole-program.
FWIW i tried what i initially thought of in c, mainly because it at least seems to push the problem around, and ended up similarly with a [pseudo] opaque type, wrapping an overloaded opaque type/function pointers pair it still has 'per type allocator functions', but I suppose it wouldn't be difficult to add some meta class, i just didn't. while I still give this code the stink eye. local/alloca'd stuff mixing, is sort of controllable by the return value of the functions implementing the 'class', due to the opacity of it all. thus there may be a single way to break that in a given set of callbacks, the pointer to the opaque thing itself. the whole nested function thing, just reeks as a workaround for keeping the number of allocator functions/function pointer types from exploding. anyhow....
private-alloca.tgz
Description: GNU Zip compressed data
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
