On 9 January 2014 17:08, Jonathan S. Shapiro <[email protected]> wrote:
> On Wed, Jan 8, 2014 at 4:53 PM, William ML Leslie < > [email protected]> wrote: > >> 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? > > > That seems like a good description of the problem to me, and that is a good point that the class of region constraints that we are willing to 'fix' must be part of the language, otherwise compilers with different treatment of source regions could admit different programs. I should ask, before I start thinking about the valid 'fixes': a little while ago, I was thinking about the class of region problems where we could insert the equivalent malloc/free calls and knew that we didn't need a collection pass. There's even a class of region problem where we can do bump allocation on a gcless heap. Assuming that such cases don't lead to additional code paths in the presence of region polymorphism, are those techniques you wanted to consider? -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
