Re: Capabilities interact nicely with Substructural Types and Reactivity

David Barbour wrote:


Ø  Creating a new instance per invocation can partially work. You still don't have determinism if the output type is 'selfish' in E's terms. It is a very inefficient and undesirable approach, especially if you do any sort of staged programming - i.e. it is not unusual to have a one time 'set up' cost for a functional pipeline to run a bunch of computations efficiently. You would be asking to pay the one-time cost every time.

Of course, but I’m trying to tease out the essence of the requirement.  Is it history independence, deterministic execution, or both?  If not both, what are the trade-offs if you have one or not the other, and if you could only have one, which would you choose?  Would it make a difference if you only permit selfless output types?

________________________
Alan Karp
Principal Scientist
Enterprise Services, Office of the CTO
Hewlett-Packard Company
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp

From: [email protected] [mailto:[email protected]] On Behalf Of David Barbour
Sent: Thursday, September 12, 2013 8:07 PM
To: General discussions concerning capability systems.
Subject: Re: [cap-talk] Capabilities interact nicely with Substructural Types and Reactivity


On Thu, Sep 12, 2013 at 4:38 PM, Karp, Alan H <[email protected]<mailto:[email protected]>> wrote:

Is making “new” not be ambient the only solution?  For example, would instantiating a new instance for every invocation achieve the same goal while allowing the object to invoke “new” during that invocation?
Creating a new instance per invocation can partially work. You still don't have determinism if the output type is 'selfish' in E's terms. It is a very inefficient and undesirable approach, especially if you do any sort of staged programming - i.e. it is not unusual to have a one time 'set up' cost for a functional pipeline to run a bunch of computations efficiently. You would be asking to pay the one-time cost every time.

Making "new" not be ambient is simple, elegant, precise, a great fit for the capability security model, and has many side-benefits that are often ignored by panicking OO programmers - such as more explicit variations of 'new' enabling orthogonal persistence and great stability across runtime code changes. And it doesn't really need to address all new objects, just those with state or identity (selfish objects).

The main problem people have with this solution is... threading 'new' through almost every method call.

I often think it might be worthwhile to find a balance between ambient-authority syntax with capability-secure semantics, such as enabling a powerbox object to be threaded implicitly but manipulated explicitly. Combined with good visualization in the IDE, we could still ensure desirable 'visibility' properties.

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