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

On Sun, Nov 3, 2013 at 2:44 PM, Rob Withers <[email protected]> wrote:

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

A promise, when created, consists of two parts: one to fulfill the promise,
one to observe the result. Something like the following:

    newPromise :: Uniqueness -> (Uniqueness * (Eventual A * Resolver A))

The 'Uniqueness' could come from procedural sequencing, or it could be more
formalized (e.g. as a linear type in its own right). The result, however,
is that we get a unique (new) eventual value and a resolver. Then we are
given some way to wait for or trigger an event on the eventual A, and a
means to fulfill the promise through the resolver (Resolver A -> A -> ()).
What we could do is make the `Resolver A` relevant (so it cannot be
dropped, must be used) and affine (so it cannot be copied or used more than
once). Those properties together would make the Resolver linear, and would
ensure that the promise is fulfilled once and only once (modulo divergence
of the resolver computation).

As an interesting side note, if you use linear types for continuations you
can also eliminate the send-response paradigm (all responses can be modeled
as sends to continuations, which cannot be dropped).


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

Sounds interesting. I spent some time dabbling in X/Open XA when developing
a transactional actors model in 2009. But I didn't like how transactions
were so fragile to denial-of-service attacks, how easily they thrash when
scaled (http://awelonblue.wordpress.com/2011/07/05/transaction-tribulation/).
Seeking
alternatives in 2010 eventually led me away from eventful update models.

Best,

Dave

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