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

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

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