Re: Are Guards Ambient Authorities?

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

> (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.)

> For this reason, I tend to agree with you in the particular case that
> the File-guard-which-accepts-only-OS-files *should* be not well-known

Indeed, but drawing the line may be tricky.

> 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?

In all, though, it sounds like I'd gone too far. I'd come to the
opinion that ocap principles would lead to all types having well-known
guards, in the end, and thought this might be problem. On two counts,
it's not. Not all types will have well-known guards and, where they
do, one can control the environment the code compiles/runs under in
order to bypass issues that would cause.

Regards,
Grant Husbands.