Re: imagining a programming language with a capability calling convention

Thanks for the mention of Pony! Pony uses reference capabilities to modify
object capabilities. David, I'm not sure if Pony does what you're looking
for, but perhaps it does.

On 13 September 2015 at 19:38, Yuvaraj Athur Raghuvir <[email protected]
> wrote:

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

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