www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - alias annotations - unque / owned / shared / lent

reply Jason House <jason.james.house gmail.com> writes:
In http://d.puremagic.com/issues/show_bug.cgi?id=1654, Andrei Alexandrescu
pointed out the following paper:
archjava.fluid.cs.cmu.edu/papers/oopsla02.pdf

Since it seems to resonate with my thoughts (on const casting), I figured I'd
try to gauge the reactions of others.  I was also lazy and stopped reading when
I hit the lambda calculus.

In a nut shell, they introduce the following types:

unique - A unique copy/reference to data
owned - A piece of data with exclusive access rights by the containing class
lent - A temporary copy of a variable.  Can be used within a function, but no
residual copy can be kept, and it can't be returned from functions.
shared - A global variable that can be accessed from many places

They also have alpha, but it seems to be a distinct type that doesn't play
nicely with anything else, and I didn't see it described up front.

Page 4 of the document gives casting rules.

I guess I've always thought of stuff in a more complicated fashion where this
type of property can be done based on write access rather than complete
ownership.
Jan 31 2008
parent reply Jason House <jason.james.house gmail.com> writes:
I probably should have included the full URL
http://archjava.fluid.cs.cmu.edu/papers/oopsla02.pdf

Both the const challenge and string alias invariant threads have mentioned
"Unique()" qualifications on types.  The paper seems to expand this in a
coherent type system that may be compatible with D.  

Jason House Wrote:

 In http://d.puremagic.com/issues/show_bug.cgi?id=1654, Andrei Alexandrescu
pointed out the following paper:
 archjava.fluid.cs.cmu.edu/papers/oopsla02.pdf
 
 Since it seems to resonate with my thoughts (on const casting), I figured I'd
try to gauge the reactions of others.  I was also lazy and stopped reading when
I hit the lambda calculus.
 
 In a nut shell, they introduce the following types:
 
 unique - A unique copy/reference to data
 owned - A piece of data with exclusive access rights by the containing class
 lent - A temporary copy of a variable.  Can be used within a function, but no
residual copy can be kept, and it can't be returned from functions.
 shared - A global variable that can be accessed from many places
 
 They also have alpha, but it seems to be a distinct type that doesn't play
nicely with anything else, and I didn't see it described up front.
 
 Page 4 of the document gives casting rules.
 
 I guess I've always thought of stuff in a more complicated fashion where this
type of property can be done based on write access rather than complete
ownership.

Feb 01 2008
parent "Janice Caron" <caron800 googlemail.com> writes:
On 2/1/08, Jason House <jason.james.house gmail.com> wrote:
 I probably should have included the full URL
 http://archjava.fluid.cs.cmu.edu/papers/oopsla02.pdf

 Both the const challenge and string alias invariant threads have mentioned
"Unique()" qualifications on types.  The paper seems to expand this in a
coherent type system that may be compatible with D.

I read it. I do like it, but I suspect it might be too complex to explain. Even justifying /one/ new keyword (unique) is hard. To ask Walter to add four (unique, owned, shared, lent), might be asking too much. One thing worth noting is that Java doesn't have const. That means that the (unique, owned, shared, lent) system has to compensate for const's non-existence. Since D /does/ have both const and invariant, it seems to me that the requirement for those other categories goes away. In the D system, there are currently three kinds of constancy: mutable (i.e., no qualifier at all), const, and invariant. Three is an odd number for computers. Two bits has four possibilities, not three. I believe unique fills the missing slot. Imagine a diamond shape. "unique" goes at the top; "mutable" goes at the left; "invariant" goes at the right; and "const" goes at the bottom. You can implicit cast by moving downwards, but explicit casts are required to move upwards. Another way of looking at it: number the constancy kinds: unique = 0 mutable = 1 invariant = 2 const = 3 Now the can figure out what can cast into what with bitwise binary operators. A can implicitly cast to B iff ((A || B) == B). The common type that A and B can both implicitly cast to is (A || B) They type that can implicitly cast to both A and B is (A && B) To my mind, a four-kinds-of-constancy system is actually simpler to implement than a three-kinds-of-constancy system. That is not to say that the (unique, owned, shared, lent) system is bad. It is well thought out, well argued, and it looks like it ought to work. But we'd have to make it work /in addition to const and invariant/, so now we'd have six keywords representing many states. How would they interact with each other? I shared+mutable different from shared+const, or does shared imply const? I think that, for the (unique, owned, shared, lent) system to work, we'd have to ditch const. (That may be a good thing - who knows?) But Walter is definitely going to want to keep invariant - because it's the key to lots of optimisation.
Feb 01 2008