imagining a programming language with a capability calling convention

I am not aware of any work done currently that uses capabilities in the
calling conventions in programming languages.

The standard calling convention is something like

      result = procedure_name(first_arg, second_arg, third_arg)

or

      result = some_object.method_name(first_arg, second_arg, third_arg)

which for this discussion reduces to the same thing.

Capabilites are worked in by limiting the access to the methods, for
instance with lexical scoping and closures in Javascript.

I am imagining injecting a capability idiom into a calling convention with
which a process that wishes to set up a call to a procedure
would need not only a capability to the procedure but also capabilites to
set the arguments.

I imagine that in practice that would wind up looking something like


           set_first_arg( first_arg.readable )

           set_second_arg( second_arg.readable )

           set_third_arg( third_arg.readable )

           set_result_destination( result.value_acceptor )

           procedure_name


where .readable and .value_acceptor are suffixes that cause the named args
and L-value to produce one-time-only capabilities to read or set their
values.


This convention might mitigate the ambient authority problems with
overridable default arguments in OO capability languages.


(1) am I making sense?

(2) is there anything currently available that works this way?


The use case for this would be a situation where some contexts are alllowed
to set the third arg and others must keep the default.

This approach -- explicit arg setters -- is superior to a convention of
having named args which are filtered based on a credential provided along
with the call because there would not have to be a filtering step. A
potential caller that is not supposed to be able to set the third argument
would
simply not have a capability to set the third argument, so the third
argument would remain the default.

The above might be revised to

           my x = procedure_name.set_up_call

           x.set_first_arg( first_arg.readable )

           x.set_second_arg( second_arg.readable )

           x.set_third_arg( third_arg.readable )

           x.set_result_destination( result.value_acceptor )

           x.call

which looks like it would easily collapse into the initial unexpanded form,
or there is nothing gained this way over allowing limited access to
different versions of procedure_name that either accept or do not accept a
third argument.

Please reply, comment or ignore

<g>

-- 
Drive the road, not the traffic.

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk