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

I had what I thought was an interesting thought.  From the perspective of Smalltalk (and other languages, grumble), functions are objects, if you are lucky.  I had the thought that perhaps the functional community views objects as functions.  Does that make any sense?


On Nov 3, 2013, at 2:10 PM, David Barbour <[email protected]> wrote:

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

To my recollection, this is precisely what Elib delivers.

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

This is what my event framework provides, with using one-way sends.

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

It seems to me that a membrane makes an excellent two- or three- phase transaction boundary.



On Nov 3, 2013, at 1:48 PM, David Barbour <[email protected]> wrote:

> 
> On Sun, Nov 3, 2013 at 1:16 PM, Rob Withers <[email protected]> wrote:
> 
> 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 know the feeling. Static typing, like many things, can be done reasonably well (ML, Haskell) or done poorly (Java, Scala, C++). 

Scala has a poorly done type system?  Have they been told?  ;)

> Why would asking non-deteministic questions be bad?
> 
> Because complexity is bugs. :)

But is the complexity inherent in non-determinism greater than or less than the complexity in building advanced, theoretical type systems, understanding them and using them, which has to deal with the non-determinism, anyways?

I am curious about how you implement your spreadsheet without state and manage nondeterminism across a partition prone network of resources.  Could you describe how this works?

> So if we need non-determinism for a problem (e.g. to make constraint solving tractable), that's one thing. If we're using it as a hack on semantics that can observe a lot of intermediate states or implementation details, that's another.

I think a good system of non-determinism is a great hack on semantics, that address those nasty details in a sensible but non-obsessive manner.

When you mention a great hack, perhaps you are thinking of Croquet: http://en.wikipedia.org/wiki/Croquet_project#Synchronization_architecture, specifically their synchronization architecture: 

Croquet's time-based synchronization abilities enable real-time, identical interactions between groups of users while dramatically reducing the need for server infrastructures to support virtual world deployment. Croquet's architecture makes it easy to develop deeply collaborative applications without having to spend a lot of effort and expertise in understanding how replicated applications work.
TeaTime is a scalable real-time multi-user architecture that is the basis for Croquet's object-object communication and synchronization. It is designed to support multi-user applications that can be scaled to massive numbers of concurrently interacting users in a shared virtual space. The most directly visible part of this architecture is the TObject class which is used to define and construct subclassed Tea objects. All of the interesting objects inside of Croquet are constructed from subclasses of TObject.
A Tea object acts with the property that messages sent to it are redirected to replicated copies of itself on other users' participating machines in a peer-to-peer network. This messaging protocol supports a coordinated distributed two-phase commit that is used to control the progression of computations at participating user sites. In this way messages may be dynamically redirected to large numbers of users while maintaining the appropriate deadline-based scheduling. Thus, TeaTime is designed to allow for a great deal of adaptability and resilience and works on a heterogeneous set of resources. It is a framework of abstraction that works over a range of implementations and that can be evolved and tuned over time, both within an application and across applications.
Key elements of the TeaTime synchronization architecture include:
A coordinated universal timebase embedded in communication protocol
Replicated, versioned objects that unify replicated computation and distribution of results
Replication strategies that separate the mechanisms of replication from the behavioral semantics of objects
Deadline-based scheduling extended with failure and nesting
Coordinated, distributed two-phase commit that is used to control the progress of computations at multiple sites, to provide resilience, deterministic results, and adaptation to available resources
Uses distributed sets


> It seems to me what you really want is a model for incremental computations that can be stopped at well-defined increments. Alternatively, you might look into approaches for speculative evaluation and retroactive correction for parallel and distributed systems (PADS). Have you read about Lightweight Time Warp (LTW)? http://cell-devs.sce.carleton.ca/publications/2008/LW08/

Thanks for the references, I’ll do some reading.

> we live in an eventful world
> 
> No we don't. Nothing in physics is eventful.

Actually, everything in physics is eventful.  An event is “something that takes place; an occurrence”.  A closed system with nothing happening, is boring.  An open system with nothing happening, is boring.  Everything in physics is about activity, or the potential for activity.  That translates to events or the potential to cause events, but that itself is an event as a bound activity of energy, even if just in potential form.  There is no matter, it is just a particular phase of energy, which is an expression of activity, which is itself an event.  All particles are events…occurrences of activity. 

Of course, I am talking about experimental physics.  In theoretical physics, anything is possible.  But we are here looking at computational physics, where anything may be possible, but constrained by performance and usability, so we tend to have some state over in the heap.

> Almost every sensor you use (mouse, keyboard, camera, microphone) is inherently time-series data without any real notion of 'events’.

An event is a time-specific piece of data.  This is why you wrote that a clock value be added to your tuples, on your blog, because they must be events, if they are to compute on a computer.  You must have time, implicit (linear stack computation) or explicit (clock value).  Clock synchronization and addressing relativistic differences are outside the scope of the reference frame of the event under investigation.

> Even a snapshot camera image is, under-the-hood, technically an integral of light information over the duration that an aperture is held open.

But the image, in its entirety, was taken at a particular measure of local time.  It is an event.

> At even lowest levels, quantum interactions seem to occur in a timeless, stateless geometry (https://www.simonsfoundation.org/quanta/20130917-a-jewel-at-the-heart-of-quantum-physics/), and topology seems to be a fundamentally better basis for comprehending the world than events.

That timeless, stateless geometry of quantum interactions is timestamped “now”.  See, no state.  The world is inherently an completely eventful.  Using a “better basis for comprehending the world”, such as using the perspective of a topology, is quite useful.  Of course, general relativity cannot escape time, as that is it’s foundation, thank you Mr Einstein.  That interactions between particles are relativistic presents no problems, given the generosity and allowances of Mr Heisenberg.  The universe is eventually consistent.

Another analogy is T = PV.  Use an analogous measure of Pressure (message, memory, disk, io pressure), and Volume (available resources) to compute a discrete Tempurature, then compute the statistical mechanics topology over the graph of resources (data-center).  If we add eventual consistency and transactions, that would add to the pressure.  No problem, more volume.  Address latency with promises.

> a shared, replicated non-deterministic state machine, with eventual and snapshot consistency
> 
> I do like those properties, and I use them. (http://awelonblue.wordpress.com/2011/10/06/vat-model-for-rdp/)

I do not see replication mentioned.  Is your ClockedVat highly-available with replication and failover?

> 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.
> 
> A discrete clock signal can be modeled operationally, imprecisely, and informally using messages/events. The problem here is that messages triggered on the same time or clock event aren't delivered or received simultaneously. A discrete clock signal can also be modeled declaratively, precisely, and formally using temporal logic or an infinite list. As an example:
> 
>   tickTockClock :: Time -> DeltaTime -> Bool -> [(Time,Bool)]
>   tickTockClock t dt b = (T,b):(clock (t+dt) dt (not b))
> 
> Given that the article is about declarative programming, I would have thought it obvious to assume a declarative representation for a clock signal. OTOH, I'm the author, and what's obvious to me isn't always clear or well communicated to my readers. 

How does declarative programming deal with network partition and non-determinism of network latencies?  The clocks are still relativistically bound, in relation to each other and event horizons abound.


thanks,
rob

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