[e-lang] Capabilities and value types?

[Sandro Magi]

David Wagner wrote:
> I don't know C# very well, but it sounds to me like C#'s structs (value
> types) are just syntactic sugar for a tuple of values.  As such, they
> don't introduce anything new to the notion of object capabilities.
>
> Just imagine expanding all stack-allocated structs into a set of variables
> (and do the obvious transformation to deal with the case where a struct
> is promoted to a heap object by boxing).  The resulting program is C# but
> without structs (value types).  This transformation doesn't really change
> anything essential about the object capability model or introduce any new
> difficulties that I can see.

Yes, this is what I tentatively concluded in my first e-mail. However, a
problem arises in the mental model: System.ValueType (ie. a struct)
inherits from System.Object (structs are auto-boxed in a reference type
scenario).

Also, structs have methods just like classes, which means they can
encapsulate permissions too, just like capabilities.

In my recent presentation
(http://higherlogics.com/Capabilities%20presentation.pdf), I use the
notion that an object reference is a capability.

  object capRef = new object(); //capRef a capability

Since struct inherits from object, you would then expect that a struct
is also a capability:

  public struct Test { ... }
  ...
  Test notCapRef = new Test(); //notCapRef looks like a capability,
                               //and should be according to the
                               //inheritance model, but isn't.

  object isCapRef = new Test();//this however, IS a capability since
                               //it's a reference type that merely
                               //happens to be a boxed value type


So I'm trying to figure out a way to explain these semantics in terms
that would make sense to C# developers that are new to capabilities.

Either a struct:

 1. is not a capability, and only reference types have capabilities
(might not be too bad as C# devs already need to know the difference
between reference and value types).

 2. is a capability that when copied/passed clones the object and
returns a new capability (like E's pass-by-copy but with mutable state;
again, the C# devs are already aware of the different semantics, but
just need a way to think about the authority-flow when programming).

Which makes the most sense? I'm leaning towards #2 since it seems
closest to the actual behaviour of structs, and it matches the
inheritance model.

Sandro