"Context capabilities" look like they might be dynamic scope, thus anti-ocaps?

[Christine Lemmer-Webber]

See this article on "context capabilities" (HT to Danny O'Brien for
forwarding it to me):

https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/

I don't know Rust, and I'm admitting to doing a "careful-ish skim", but
from what I can tell, this looks like dynamic scope.

Which would be pretty frustrating ocap-wise, because I consider ocaps to
be the realm of *lexical scope*, and dynamic scope to be the realm of
ambient authority and confused deputies?

Could someone more in Rust-land (Alan maybe?) give a better assessment
if my read looks right?

[Matt Rice]

I don't think it actually is dynamic scope, It adds an extra set of parameters
to a 3 party situation. One party, the trait declaration has a subset
of these parameters,
The other 2 parties (the caller, and the callee) have the complete set
of parameters.
Quite critically from the perspective of the caller and the callee
everything should be still scoped statically.

Traits add a mechanism not unlike figure 10 of the capability myths
demolished paper
Which limits what capabilities can be granted across the dotted line...
https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf

Not all is well however consider the Ord,

enum Ordering {
Less,
Equal,
Greater,
}

trait Ord {
fn cmp(&self, other: &Self) -> Ordering;
}

I'm going to make up some syntax to make it look more like parameter
passing and use ((extra parameters))
if we add some `context` to it to reverse the order

impl Ord for Foo {
// reverse_order flips it so that less is greater and greater is less.
fn cmp(self: &Foo, other: &Foo)((reverse_order: bool)) -> Ordering
}

I could explain in more depth, but it breaks the transitive property
if you specify different reverse_order contexts.

"It is a logic error for a key to be modified in such a way that the
key’s ordering relative to any other key, as determined by the Ord
trait, changes while it is in the map. This is normally only possible
through Cell, RefCell, global state, I/O, or unsafe code."
https://doc.rust-lang.org/stable/std/collections/struct.BTreeMap.html
Add "or add context via the with keyword" to that list of logic errors.

What this proposal does is it allows an additional parameter to every
trait, you could add it explicitly to every trait already to remove
the dotted line in the figure.
fn cmp<T>(&self, other: &Self)((T)) -> Ordering // I've mentioned this
is a bad idea when it comes to comparison which relies on the absence
of additional context...

It is salvageable if you can explicitly state in traits like Ord that
there may not be any additional context or unit context like
Which would end up with something like:
trait Ord {
fn cmp(&self, other: &Self)((())) -> Ordering;
}

The key thing is that existing rust code can already
fn foo<T>(&self, other: &Self, _: T) -> ...;

Then callers must specify foo(..., ()) and add <()> in the type (When
they want a zero information value to pass).

I am inclined to believe that there is value in something which when
unspecified by the caller defaults to the unit type/value
implicitly...
but must be explicitly opted into by the trait, and when the trait
implementer also opts in the caller must explicitly specify.

but there is a delicate balancing act between the strong property
which were the impetus for traits/type classes that traits like Ord
require and rely on,
and the weaker property desired by the above post.

With the strong property being that there is a single unique
implementation for each type, and the parameters are a closed set
specified by the trait...
the proposal weakens/drops that last property, but it definitely seems
possible to do something in between where the trait gets to choose
whether it is open or closed...

I would hazard a guess that it is roughly equivalent to combination
type-classes/traits along with row polymorphism
Ur/Web is a language (statically scoped) with both which maintains
some strong security properties.

Not going to comment on calling these capabilities though

[Will Sargent]

I'm from Scala-land, so those look like implicits to me, rather than capabilities.

I'd say effects are much more strongly related to capabilities:

https://groups.google.com/g/friam/c/z5SIvlmFJAA (thread on friam discussing this)

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CACTLOFrQCq6fZKSi3F03ReGruRoCDTQZgNJVZQFw4Xz3GEESjQ%40mail.gmail.com.

[Alan Karp]

Their "capabilities" are not ocaps.  They use the word in the sense of what functionality these "capabilities" provide.  

Note in the first code block that any piece of code with access to the module arena can use the basic_arena declared in that module even if it isn't passed explicitly.  That looks like an ambient authority to me.  In fact, that's the whole point, to provide access to something deep in the call chain without needing to include it in every call.  The result is that you can't withhold it or attenuate it deeper in the call chain.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87ilvf9bfi.fsf%40dustycloud.org.