Re: imagining a programming language with a capability calling convention

I came across Pony recently.

Pony is an object-oriented, actor-model, capabilities-secure, high
performance programming language.

http://www.ponylang.org/

Regards,
Yuvaraj
On Apr 3, 2015 10:06 AM, "David Nicol" <[email protected]> wrote:

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

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