Re: how to extend a capability on a data source?

I realized that I failed to ask for clarification, to something you wrote, David.  You said: “If you want to guarantee that a promise is completed once and only once, substructural typing would do the job”.  How does substructural typing do this, and how does it relate to linear and ordered type systems?

I also thought a bit more about adding another object table reference - the question to the send.  If we allow sending to answers, then a message send to the answer id of the continuation, from the sender, could route back to the message send at evaluation vat, so we don’t need any change to Elib’s tables.   So that object ref is bi-directional and it "is" the message send.

Just allow a promise immediate access to the far ref to the executing msgSend (on top of the continuation id) and allow sending to that guy.  Hang event listeners off the redirector, so when an event fires through the continuation from the eval site, the send site can react.  I already have event registrations working, though not inserted into the redirector layer.  We will need to work out replication and failover semantics, and replication is coupled to vats and so also queues.

In fact, that is the sort of thing that is needed, is it so?  Modify Elib's send-queue to be replicated and transactionally aware.  Make it X/Open XA compliant and forge a three-way commit, where the middle way is the replication to peer vats as well as notification to the transaction mgr.  The resolution or smashing of a message send to the continuation (send<vat2> -> redirector<vat1> -> resolver<vat1> -> promise<vat1>) is just another firing event.  So is the middle way of a transactional commit notification.

thanks,
rob

On Nov 3, 2013, at 12:16 PM, Rob Withers <[email protected]> wrote:

> 
> On Nov 3, 2013, at 10:24 AM, David Barbour <[email protected]> wrote:
> 
>> On Sun, Nov 3, 2013 at 9:05 AM, Rob Withers <[email protected]> wrote:
>> 
>> how can one distinguish that an arg is immediate or eventual
>> 
>> E doesn't use static typing. That doesn't mean ocap languages cannot cannot use static typing. Though, I'd not recommend Java-like types. Instead, use structural typing, substructural typing, and dependent typing. If you want to guarantee that a promise is completed once and only once, substructural typing would do the job.
> 
> Allow me a moment to lament the desire by various parties, near and far to protect us from ourselves.  In this case, static typing, particularly stupid static typing <SST>.  I totally love the constructs one could use within scala, to provide a safe mutation barrier for a promise to a ref.  But still, you have a ref.  Having to wrap a proxy, then deal with identity, sucks.  Worse, and I am not sure how scala could solve this issue, is that a promise ought to be type inferred as the resulting type.   This way you could immediate send to the ref, have it be type-confined, and have it play as a send returning another typed promise.  Unfortunately, I think the right solution to this is privileged ref mutation in the jvm…but it would require a capabilities model of system calls, wouldn’t it?  We would need internal sudo.  JDK 9?
> 
> That is very interesting reading on different type systems - a whole new world to me.  If I am grokking right, scala and Smalltalk are linear type systems, while Java is a nominative type system.  Elib capabilities are affine, while Hadoop and other high-availability systems requires being relevant.  To combine three, we get: 
> linear types for the immediate call stack
> affine types with mutating eventual references, including resolve() and smash() for resolution and revocability
> relevant types for high-availability
> 
>> I was thinking of “tracking” the send, itself, in some respects, and being able to manage it.
>> 
>> I can't think of any good semantics for tracking a 'send'.  I suppose you could return a variation of a tracking number or something to the sender, but unnecessarily asking non-deterministic questions (has the message been processed yet?) isn't a good thing, nor would there be good (deterministic, sensible) semantics for stopping the message.
> 
> Just make it a 4th registration in the object tables.  Then add the behavior we want, just like any other send.  Each prior event registration on the send would result in an extra listener registration.  
> Each send will stretch as:
> the receiver (question or export)
> the promise (export)
> the continuation (answer)
> the send (question)
> a listener per event registration (import)
> Why would asking non-deteministic questions be bad?  Asking the question without knowing you’ll get the answer, in order, isn’t bad, but using that to ensure transactional state is.  So stretch the transactional state back to the first cause, the sender, to resolve relevant type system issues.  Resolution of the continuation, at the sender, will result in a commit sent back one-way to the send transaction.  It would implement eventual consistency.  Slower is faster.
> 
> Stopping the message would be best effort.  More like monitoring, through the event registrations, for stalls and such.  If we kick off 3 computations across the same data, a la Hadoop, then only 1 wins during reduce.  Link that 1 winner to the transactional commit of the result, which could itself be replicated for high-availability.  So with 3 workers, each with a replication of 3 with their results, and the eventual commit, there would be 9 replicas, where only one set of 3 results is committed, with failover, while the others would be explicitly cancelled or tenured.
> 
> 
>> Could you mention the deficiencies of message passing, that is problematic to implementing data-flow
>> 
>> It isn't especially difficult to implement dataflow above message-passing. That doesn't mean message passing is a good way to understand dataflow. Indeed, I believe it would be better to formally understand message-passing in terms of a temporal dataflow model, making the intermediate state and ordering issues much more explicit. 
>> 
>> Message passing, in general, has a lot of deficiencies: 
>> http://awelonblue.wordpress.com/2012/07/01/why-not-events/
> 
> I have seen this link before.  I like many of the ideas, but we live in an eventful world and even global state would need to be transactional and maintain logs of events (state transitions) so that state could be reconstructed on failure, by replaying changes against a snapshot.  I suppose what we are discussing, or at least my position, is best described as a shared, replicated non-deterministic state machine, with eventual and snapshot consistency.  
> 
> One of the pages on that blog, on declarative state machines: http://awelonblue.wordpress.com/2013/03/27/declarative-state-machines/, suggests to adding a discrete clock signal.  I do not know if it is meant to mean distinct or prudent, but either way, that certainly sounds like an event to me.
> 
> thank you,
> rob

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