[cap-talk] Are Guards Ambient Authorities?
kpreid at mac.com
Thu Oct 8 09:32:43 PDT 2009
On Oct 8, 2009, at 10:19, Grant Husbands wrote:
> Kevin Reid wrote:
>> These are not ambient; they are "well-known".
> Fair point. I'd managed to misunderstand "ambient" as meaning
> 'available to all code', but these are fully designated and so aren't
> ambient. My apologies to all.
> "Well-known" appears to mean 'part of the set of designated
> operations/objects available to all code by default'.
There's another aspect: objects like the integer guard are often hard
to *exclude*; e.g. I can extract the integer guard from
the .__getAllegedType() of any object which alleges to have a method
accepting integer arguments.
>> (It's also debatable whether they're "authorities".)
> The way I think of things, and the way I thought OOP/ocap dualism
> worked, all objects are authorities, but that seems to disagree with
> accepted terminology and is also perhaps not useful; I'll try to
> correct my usage.
> In terms of objects, are all objects that can access (not necessarily
> mutate) mutable state considered authorities? (This wouldn't seem to
> cover all possible implementations of unsealers/brands, but maybe they
> aren't authorities.)
Anything that reads or writes mutable state is definitely an
authority. Any sealer or unsealer is too.
I don't know how to classify an object definitively as "not an
authority". Looking at the case of sealers, perhaps "is not a
participant in rights amplification" also applies, but is that an
>> In general, *data structure* guards may be well-known; guards for
>> external authorities (and possibly even for internal ones, mutable
>> objects?) should not.
> An interesting summary. If I run across code that uses integer guards
> but really only needs some simpler guarantees, though, it sounds like
> I can control the environment the code runs under in order to effect
> laxity, anyway, if I'm brave.
> Also, don't most types have some implicit interface contract that is
> not just method signatures, and isn't this part of what guards are
> used to protect?
Yes. Method signatures by themselves are worthless.
In principle, it is possible to use the auditor facility to guard on
objects obeying some particular contract and yet otherwise be
arbitrarily implemented. In practice, this is a hard problem (it boils
down to correctness proofs, so you can do it semi-easily for limited
programs and not at all for arbitrary programs).
Kevin Reid <http://switchb.org/kpreid/>
More information about the cap-talk