• Jason House (11/11) Jan 31 2008 In http://d.puremagic.com/issues/show_bug.cgi?id=1654, Andrei Alexandres...
• Jason House (4/21) Feb 01 2008 I probably should have included the full URL
• Janice Caron (39/42) Feb 01 2008 I read it.

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.

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.

"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.