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

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