No subject

[Brian T. Rice]

At 02:35 AM 4/1/00 PST, Jason Marshall wrote:
>>It is generally understood that my project, at least, is only
>>for a "TUNES--" ... Thus, I'm not now considering _all_ the
>>goals of TUNES. My main focus now has been to achieve efficient
>>storage management. 
>
>My current focus is on a GC framework (rather than a one-size-fits-all
>GC), and after the groundwork is in place, I'm going to attack the
>problem from the top, down.  I figure for security, and certain size &
>latency optimizations, that being able to prove something immutable
>would be a fairly useful thing.  While the trivial case is fairly 
>simple
>(no mutators, and no shared data with mutators, recursively), some 
>other cases where the sharing time extends only as far as the end
>of the call, will be harder to construct proof systems for.  The 
>difference between immutability and almost-immutability is a race
>condition.
>
>I still haven't decided what precisely the code is going to look like,
>only the shape of the vessel into which it will fit.  Coding around a
>void in order to determine its shape is only going to get me so far.
>Alas, at the rate I am currently progressing, I have plenty of time
>before I run into that hurdle.

"Abstract Models of Memory Management" at
http://www.cs.rice.edu/CS/PLT/Publications/fpca95-mfh.ps.gz

This paper deals with rewriting semantics used as a memory management
framework, particularly related to the kind of rewriting used in Maude.

~