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: > > The second question: assuming that it IS important, can anyone identify a > > corresponding type-safe pattern? I'm stumped on this one. > > I think you forgot to qualify this with 'type-safe pattern someone > would actually consider using.' > :-) Here's what I've got so far: 1. If we knew the concrete type, then of course we could just stick one on the stack and then pass it by reference to be overwritten down in the platform-specific code. The problem is that we don't know the concrete type, so that's not doable. 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. 3. Somewhere in the middle of this it occurred to me that nobody talks about doing alloca() in safe languages, and I took a moment to ponder that. We could imagine something like: alloca T : () -> [currentStackRegion] T * that's close to what we're after, except that we want to defer initialization to some inner procedure. But that in turn led me to the notion of a stack-allocated heap: AllocHeap(szInBytes) : size_t -> [currentStackRegion] HeapRef that is: introduce heap types as first class, and then pass them around. The problem with this is that we now need to make the region ID first class, and we likely need to make it dynamic (though possibly with static constraints). At the moment, that's the best I've got. Reactions/thoughts?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
