[cap-talk] Objects and Facets

[Mark Miller]

On 8/7/06, Ian G <iang at systemics.com> wrote:
> Mark S. Miller wrote:
>
>
> > The object-capability model is explained starting in section 9.1 p64. There we
> > state:
> >
> > * An object is either a primitive or an instance. Later, we explain three
> >    kinds of primitives: data, devices, and loaders. Data is immutable.
> > * An instance is a combination of code and state. We say it is an instance of
> >    the behavior described by its code. For example, in an operating system
> >    context, we say a process is an instance of its program. In a lexically
> >    scoped lambda language, a closure is an instance of its lambda expression.
> > * A reference provides access to an object, indivisibly combining designation
> >    of the object, the permission to access it, and the means to access it.
> > * A capability is a reference to non-data.
>
>
> Reverse-engineering the above, is it fair to suggest:
>
> * Non-data is objects of the forms:  devices, loaders, instances?


Good question. Unfortunately, no, since "data, devices, loaders" are
not meant to be a complete enumeration of primitive objects. There is
no generic such enumeration -- each particular object-capability
system will provide certain objects primitively, but which these are
will differ from system to system. For example, most provide some
collection types primitively, such as lists, maps, and sets in E, or
Nodes, Segments, and Pages in KeyKOS. However, this is not
fundamental, as these could be built from instances.


> Or
>
> * Non-data is objects that are non-immutable?


No again, since some instances and some non-data primitives will also
be immutable. For example, in most object capability systems, an
opaque object with no state and no operations still has an unforgeable
unique identity, which thereby goes beyond the properties of pure
data. Let's call such an object a "token". In E,

    def makeToken() {
        def token {}
        return token
    }


> Still searching for the difference between the capability and the
> object/reference here;  it seems that you are suggesting that
> capabilities are in the broad sense a limited subset of objects
> (must include some sense of dynamic state).

Since data provides only knowledge, we need not distinguish between
access to the data and the data itself. For non-data, this is not
generally true.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM