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

David, really, this is all at least an order of magnitude harder to
understand than it would be if you'd show some example code. Thanks.


On Sun, Nov 3, 2013 at 9: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.
>
>
>> 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.
>
>
>> 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/
>
>
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>


-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM

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