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

On Nov 4, 2013, at 12:44 AM, David Barbour wrote:

> On Sun, Nov 3, 2013 at 9:06 PM, Rob Withers <[email protected]> wrote:
> 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?

Possibly relevant:
Acknowledgments section of:
SCHEME: An Interpreter for Extended Lambda Calculus
Author: Sussman, Gerald J.; Steele, Guy L., Jr.
Citable URI: http://hdl.handle.net/1721.1/5794
Date Issued: 1975-12-01

'Sussman suggested the experimental approach of actually building an "ACTORS interpreter". This interpreter attempted to intermix the use of actors and LISP lambda expressions in a clean manner. When it was completed, we discovered that the "actors" and the lambda expressions were identical in implementation. Once we had discovered this, all the rest fell into place, and it was only natural to begin thinking about actors in terms of lambda calculus.'
https://en.wikisource.org/wiki/Scheme:_An_Interpreter_for_Extended_Lambda_Calculus/Whole_text

Jonathan

> There is some truth to that. Objects would certainly be more compositional if modeled as dependently typed functions. But how functional programmers think of OO is probably shaped more by Luca Cardelli's and William Cook's works on the subject.
> 
> 
>> 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.
> 
> When I say "ensure", I think I'm saying something stronger than you're hearing. Elib does not make a *static guarantee* that a resolver is called exactly once. If a programmer simply drops the resolver, it is never called, and thus Elib needs a concept of "broken" promises. It is also possible for a programmer to call a promise twice, which Elib addresses using state. With linear types, you would be unable to drop the promise, and unable to call it twice: the type system would reject the program.
>  
> 
>> 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.
> 
> You statically enforce that nobody forgets to respond using the one-way send, and that nobody calls the one-way send twice?
>  
> 
> Scala has a poorly done type system?  Have they been told?  ;)
> 
> Yep. 
> 
> http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu
>  
> 
>> 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?
> 
> Considerably so, yes. Especially since these "advanced, theoretical type systems" are considerably SIMPLER than the type systems you're probably using, and easier to understand. Advanced doesn't mean more complicated, especially in computer science. 
> 
> And the "which has to deal with the non-determinism anyway" is generally false. There is a great deal of non-essential non-determinism. The only real issue we need to deal with is disruption, not update order.
>  
> 
> I am curious about how you implement your spreadsheet without state 
> 
> I would need to use memory to implement an efficient spreadsheet in a Von Neumann computer, i.e. to cache results. Of course, that doesn't mean you can model state (e.g. an accumulator) within a spreadsheet. 
> 
> In my RDP model, real state (the ability to accumulate information over time, for the past to influence the future) is available only through observing and influencing external resources. This enables me to update the code that observes and influences state without losing any information. (By comparison, a lot of reactive models like FRP tend to internalize state via modeling folds or integrals over time. Consequently, runtime update of code either loses state or requires a hack on the model.)
>  
> 
> manage nondeterminism across a partition prone network of resources.  Could you describe how this works?
> 
> Yes. I earlier pointed you to an article on it (Vat model for RDP).
> 
> Since I use dataflow instead of general messaging, I can guarantee certain properties about the update 'messages' that are not true of messages in general: updates on different values are commutative, updates to the same value are composable, and updates can be batched in useful ways. Non-determinism in update arrival time is addressed by speculative evaluation, potentially some retroactive correction. 
> 
> Of course, disruption is possible and is the only 'real' non-determinism in my model, but even there I can ensure that disruption logically occurs at a precise instant in time, which can be conveniently placed between batches, which results in very smooth failovers.
> 
>  
> 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.
> 
> Non-determinism is certainly an effective way to write code where there are no obvious bugs. But it makes testing much more difficult, and it makes the bugs you do find very difficult to reproduce or isolate, and it usually doesn't lead to better performance.
> 
> http://imgur.com/pPeBAIJ
> 
> 
> 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:
> 
> I'm familiar with it. Tea-time is certainly interesting and worth learning and comprehending. Unfortunately, by nature, it is neither secure nor very scalable, and it only works well with low human-to-computer bitrates (since high rate devices, e.g. LEAP motion or Myo, would require too many transactions; videoconf had to be integrated using an external protocol). 
> 
> 
> 
> Actually, everything in physics is eventful.  An event is “something that takes place; an occurrence”.
> 
> To avoid equivocation, we should speak of 'event' as it is used in the Why Not Events article which defines events as a conceptually instantaneous value that effects or reports change - e.g. a message, or a transaction. Under that definition, nothing in physics is eventful. 
> 
> The definition you presented doesn't seem to offer any useful distinctions. You might as well be saying 'pattern' or 'object' as 'event'.
> 
> 
> That timeless, stateless geometry of quantum interactions is timestamped “now”.
> 
> I'm quite certain that 'timeless' was meant literally.
> 
>  
> The universe is eventually consistent.
> 
> I think the phrase "not even wrong" is suitable for statements like this one.
>  
> 
> Address latency with promises.
> 
> I prefer to address latency with latency types.
>  
> 
>> 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?
> 
> If the network partitions, I prefer to model disruption explicitly, leave failover behavior to the program code, and support resilience (quick recovery or self-healing when the cause for the problem is gone) via reactive models. This behavior is sensible in every domain I've ever worked in - e.g. robotic control software, autonomy, user-interfaces, games - whereas transparent partitioning is a genuinely stupid idea.
> 
> That said, I do have approaches to model replication of code and data. Not at the vat layer, but rather at the resource layer. The idea of replicating data isn't unusual, and certain data models (i.e. with monotonic or commutative writes, or lattice types) can support writes well enough even while partitioned.
>  
> 
> 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.
> 
> There are a number of mechanisms. I favor latency and location types, a formal model of partitioning and temporal properties, with explicitly replicated resources where necessary. Temporal logic, time warp, and cellular automata are related. 
> 
> Some people favor lattice variables or other commutative write models. Look up the CALM conjecture, part of the Bloom project.
> 
> Best,
> 
> Dave
> 
> 
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk