On Tue, Jul 30, 2013 at 4:54 PM, Jonathan S. Shapiro <s...@eros-os.org>wrote:
> >> I also don't like the last-in-first out discipline, since it seriously >> limits what regions can do (as I mentioned in my practical examples). >> > > Understood. But that's one of the *defining* characteristics of regions. > In order to type them sensibly, you need a region subtyping relation. LIFO > order ensures that. > I'm okay with strict subtyping. I just want several regions hanging off a common ancestor which can all reference the ancestor but not each other. For example, 200 regions, each one for an in-flight web-request.. They can't touch each other, and the ancestor can't touch them, but they can all touch the ancestor. It's necessary to break LIFO to be able to use regions for this use-case, otherwise you can't free a requestor region when that requrestor finishes, without freeing all requestors before it. ..or am I implying too much in LIFO? Is LIFO only describing a single branch of region subtyping, in which case I'm a-okay with it. > I guess this is why I like thinking of "lifetimes" as an independent >> feature, because I would like it solved for generalized GC-able objects >> whether or not regions are implemented. Perhaps this is just a linguistic >> difference, since we could call value-type box a region. Seems like a >> terminology mismatch to me though. >> > > It's not just a lexicon difference. The kind of generalized lifetimes you > seem to be describing don't satisfy the subtype relation that is necessary > for region inference. > Right, that was my instinct too. I really want CLR non-region heap collections of value types to be able to return interior pointers to payloads. This seems to be easy to do with this Rust-ish generalized lifetime system.
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
