On Wed, Jan 8, 2014 at 4:53 PM, William ML Leslie < [email protected]> wrote:
> > Actually I meant /this/ metasyntactically, representing some idiom of > interface usage. Ah, the difficulties of discussing language. > It could be worse. We could be debating metaphysics. :-) > > Hmm. Maybe that's too strong. It seems pretty clear that the compiler > > shouldn't go magically moving things into the heap when we are under a > > noheap constraint. The more problematic case is when the effect type is > > parametric. In that case, from a local partial typing perspective, we > may or > > may not end up under a noheap constraint. The problem in this case is > that > > moving an object into the heap "fixes" the noheap constraint to !noheap, > > where we may really need to be able to instantiate either way. > > This is probably a discussion for another thread - it's a question of > what we can and can't do with region and effect types. I don't think > this problem occurs for interfaces, however you want to represent > them: they are immutable and so can be copied as needed and should > probably be value types; so the issue is the region constraint that > they propogate from the underlying object. > > If you're allocating the underlying object here and passing it to a > provided function, the region of allocation is parametric, and there > are several implementation techniques. However, if interfaces are > value types, then satisfying region constraints can usually be left to > whatever function we pass the interface to (if it wants to store them > on the heap somewhere, it can allocate an interface instance on the > heap). OK. I think we agree on the character of the problem, which is more a matter of pragmatics and taste than typing. Here is my characterization: 1. Region typing can [conservatively] detect when problems occur. This means that we have a mechanism for reliable error diagnosis. 2. There exists a [very conservative] fix for any region typing violation: move the violating object to the GC heap. This fix is "correct" from the perspective of typing and computational semantics. There is an open question about whether/how to apply this fix in the context of modular compilation. 3. Systems programs admit concerns of temporal semantics, promptness, and storage allocation in addition to operational/functional semantics. We do not have a generalized model for how to simultaneously address all of these at once. 4. From a human-intuitive perspective, some fixes seem reasonable, but this is a matter of taste and our sense of taste may prove optimistic. 5. When we lack sufficient arrogance -- er, um, confidence -- in our sense of taste, we should resort to warning and errors rather than "magic" fixes. As a concrete example of a human heuristic: if /ob/ lives in region /r/, and we are asked to form an interface on /ob/, the resulting interface object /if/ can "sensibly" be allocated in any region /r-if < r/. It does not seem like a stretch to conclude that /if/ can be placed in the same region as /ob/ without violating any human intuition. But: any such intuition must be captured explicitly in the language specification, and, ideally, the language should admit mechanism[s] by which the programmer can explicitly override these heuristics. Does this capture the issue? What am I missing? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
