Cells compared to Flow-Based Programming

Sohail Somani wrote:
> Frank Buss wrote:
>
>> What is a Cells synapse?

I am surprised Pascal Costanza has not answered this already. (I slay
myself.) Synapses are anonymous Cells local to a rule which mediate not
a CLOS slot, rather any arbitrary form within a larger Cell formula (er,
Lisp form that calculates a Cell value).

One possible use: If I have an expensive calculation in a rule and any
of its inputs tends to jump around a lot in ways that matter but not all
that much, I can wrap the form that accesses that bad boy in
(with-synapse....) wherein I make sure the other value has changed by
amount X before "firing". The Cell to which I am local then runs.

> I didn't used Cells very much, but I don't think
>> this maps very well, because in FBP all processes are running in
>> parallel,
>> which is not possible with Cells.
>
>
> Why is it not possible?

Currently Cells enforces what I call "data integrity". See the manifesto
for details, but basically it means things should happen in order. If I
depend on A and B and B happens also to depend on A, when A changes I
want to see its new value and the new value of B that results from the
change to A. This and other matters require strict enforcement of linear
calculation (tho in some cases folks would be free to charge ahead with
their calculations, they just gotta check that they are free to go
ahead). btw, where Philip Eby discusses the name "Trellis" for that
package he mentions Gerlentner's Trellis likewise involved a master
clock -- er, that is how Cells does its integrity thing.

All that said, originally things were much more wild wild west and stuff
did get calculated out of order and I wrote hundreds of thousands of
lines of Lisp that way. Basically the universe is smooth and one get out
of synch for brief periods of time and catch up with commensurately
small deviations from goodness having arisen. Until I did RoboCup, then
the wheels came off and I did the integrity thing.

I really do not know the issues in parallel programming. I suppose one
could just let the data flow through the dependency graph willy nilly
without regard to a master clock and based on my cited experience I am
sure it would go fine, one would just have to do a little extra work
(FLW) where "close" is not good enough.

kt



--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

Frank Buss wrote:
> George Neuner wrote:
>
>
>>The simplest of the software dataflow models is one of server
>>processes communicating by messaging, but that is not the only
>>possible model. Somebody recently mentioned the Linda programming
>>language - a somewhat different implementation where all communication
>>between application units is performed through a software associative
>>memory.
>
>
> Erlang has another nice idea for connections between processes, like the
> mailbox functions in LispWorks.
>
>
>>You're also getting too caught up in the communication abstraction.
>>The book's "information packets" are nothing more than the logical
>>"wires" connecting the functional units of the application.
>
>
> I think this is wrong, because the information packets are the data, which
> are traveling through the connections.


I am reminded of the discovery that electric current is a moving hole. I
certainly think of Cells as dataflow, but /that/ datum just flows from
the cell that calculated it to the cell that uses it to calculate some
other datum potentially quite different. Ah, the box is now 3cm wide?
Then the launch decision on all ICBMs aimed at Canada is now t.
Something like that.


>
>
>>It really
>>doesn't matter whether the wiring is implemented using IPC messaging,
>>in(ter)-process signaling, function callbacks, shared memory or actual
>>wires.
>
>
> Yes, this is true. I think it could be very useful for high performance
> applications with multiple CPU cores and multiple computers.
>
>
>>I don't know too much about Kenny's Cell projects except from skimming
>>what he has written here, but IIUC, Cells allows objects to be linked
>>into dependency notification chains so that a change to one object can
>>affect all its dependents. AFAICT from such a simple understanding,
>>Cells qualifies as an implementation of dataflow.
>
>
> This depends on how you define "dataflow" :-)
>

Word.

kenny

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

Frank Buss wrote:
> Ken Tilton wrote:
>
>
>>FBP sounds as if one thinks about a pipeline of processing and
>>transformations one wants for state.
>
>
> Yes, that's right. The author compares it with the pipe operator found in
> DOS and Unix shells: There are lots of simple programs, like sort, unique
> etc., and you can feed the output of one program to the input of another
> program.
>
>
>>We may have dataflow in both models and much different programming
>>experiences. But the IBM folks report the same high productivity Cells
>>users enjoy, so perhaps the key is exactly what Brooks identified:
>>decomposing the complexity of the the interdependence of large numbers
>>of kinds of state. As long as one does that (and both seem to) we're good.
>
>
> While trying to implement the telegram problem in FBP Lisp, this was
> exactly my feeling: You can concentrate on writing just one process, with
> explicit defined input and outputs. Then you can connect the components and
> the program just works (if you've tested the components before and the
> specification of the ports matches).
>

Yes, that is the right phrase. After we invented Cells (three were
present at the creation) we would turn to each other regularly and say
in quiet awe, "It just works" after trying something ridiculously
unlikely. And we said it more as if it were a question: "How can it just
work?".

I think the answer is we all should have been programming with language
constructs supporting cause and effect all along, then it would not seem
so odd. I mean, the world Just Works, right?

Those were heady days, a true sense of having stumbled onto something.
Only took a day to implement, too. Another message from god in there
somewhere.

kt


--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

Rainer Joswig wrote:
> In article <tvmp8kuaxn1f$.kpjws99l19su$.dlg@40tude.net>,
> Frank Buss <fb@frank-buss.de> wrote:
>
>
>>Alex Mizrahi wrote:
>>
>>
>>>so IP is just a fancy way to say "any object"? maybe it matter for
>>>distributed implementations, where IPs have to be serializable
>>
>>Yes, in the FBP book an IP can be any object. There are special IPs, like
>>brackets for implementing sub-streams. But this is just a concept, not
>>built into the framework.
>>
>>
>>>in Cells terminology, process is model (class), process instance is an
>>>object, interconnect is synapse.

Sorry, I missed this. In vanilla Cells, the "interconnect" is as dumb as
it can be: all you can do is leave a wake-up call with any Cell you use
(well, I mean, that happens transparently by default), But the idea is
the same. If you ask me my value, when my output changes you just get an
unspecific* wake-up cal* that tells you /something/ you used changed (or
you are being brought to life at make-instance time.

A synapse (as described elsewhere) improves this somewhat by letting a
subform of a rule compute a local value and have its own dependencies,
but then it is the same: folks still get a non-specific Recompute! command.

* I lied. There is a special bound to the Cell that changed. But I have
never used it for anything other than debugging, when I could not
understand why a rule was running.

kt

Rainer Joswig wrote:
>
> See the history of Scheme:
> http://research.sun.com/projects/plr...2006public.pdf
>
> Scheme was created to understand the Actors theory from Carl Hewitt.
>
> Inspired in part by SIMULA and Smalltalk, Carl Hewitt
> developed a model of computation around ³actors²
> Every agent of computation is an actor
> Every datum or data structure is an actor
> An actor may have ³acquaintances² (other actors it knows)
> Actors react to messages sent from other actors
> An actor can send messages only to acquaintances

That sounds different, as if one is writing code that says, OK, now send
a message to precisely here. That is classic imperative management of
state change and its consequences by the programmer, and has nothing of
the declarative quality of Cells.

I would suggest the metaphor of a spreadsheet, but that has actually
been resoundingly and repeatedly demonstrated as insufficient to make
the point.

kt

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

Frank Buss wrote:
> Sohail Somani wrote:
>
>> Frank Buss wrote:
>>
>>> What is a Cells synapse? I didn't used Cells very much, but I don't think
>>> this maps very well, because in FBP all processes are running in parallel,
>>> which is not possible with Cells.
>> Why is it not possible?
>
> We have to ask this Kenny, but I don't think that Cells is multithreading
> safe and the concept of Cells is not to have many parallel running
> processes.

Gotcha but the general concept can be executed in parallel if done properly.

Or maybe I should say "done a specific way".

Ken Tilton wrote:
>
>
> Rainer Joswig wrote:
>
>>
>> See the history of Scheme:
>> http://research.sun.com/projects/plr...2006public.pdf
>>
>> Scheme was created to understand the Actors theory from Carl Hewitt.
>>
>> Inspired in part by SIMULA and Smalltalk, Carl Hewitt developed a
>> model of computation around ³actors² Every agent of computation is an
>> actor Every datum or data structure is an actor An actor may have
>> ³acquaintances² (other actors it knows) Actors react to messages sent
>> from other actors An actor can send messages only to acquaintances
>
>
> That sounds different, as if one is writing code that says, OK, now send
> a message to precisely here. That is classic imperative management of
> state change and its consequences by the programmer, and has nothing of
> the declarative quality of Cells.

Btw, I am not disagreeing that Actors sounds like dataflow, but as Mr.
Buss says it depends on the meaning of the word "dataflow" and as I said
the devil is in the details, tho in this case this is no detail: the
beauty of a spreadsheet is that I never worry about who I have to tell
when I change, the software tends to that automatically, nor do I have
to step back from writing my formula to do explicit stuff (as in a
subscribe/notify pattern) in order to get updated -- I just write my rule.

Same with Cells.

>
> I would suggest the metaphor of a spreadsheet, but that has actually
> been resoundingly and repeatedly demonstrated as insufficient to make
> the point.

Oops.

kt

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

Ken Tilton wrote:

>> Rainer Joswig wrote:
>>
>>>
>> I would suggest the metaphor of a spreadsheet, but that has actually
>> been resoundingly and repeatedly demonstrated as insufficient to make
>> the point.
>
> Oops.

Actually, in the latest version of Excel, if your addins are specified
as reentrant (Excel4 API-using addins are not, iirc), MS Excel may
calculate cells in parallel.

Atleast thats what I last heard when dealing with Excel 12 propaganda.

Ken Tilton wrote:
>
>
> Ken Tilton wrote:
>
>>
>>
>> Rainer Joswig wrote:
>>
>>>
>>> See the history of Scheme:
>>> http://research.sun.com/projects/plr...2006public.pdf
>>>
>>> Scheme was created to understand the Actors theory from Carl Hewitt.
>>>
>>> Inspired in part by SIMULA and Smalltalk, Carl Hewitt developed a
>>> model of computation around ³actors² Every agent of computation is
>>> an actor Every datum or data structure is an actor An actor may
>>> have ³acquaintances² (other actors it knows) Actors react to
>>> messages sent from other actors An actor can send messages only to
>>> acquaintances
>>
>>
>>
>> That sounds different, as if one is writing code that says, OK, now
>> send a message to precisely here. That is classic imperative
>> management of state change and its consequences by the programmer, and
>> has nothing of the declarative quality of Cells.
>
>
> Btw, I am not disagreeing that Actors sounds like dataflow, but as Mr.
> Buss says it depends on the meaning of the word "dataflow" and as I said
> the devil is in the details, tho in this case this is no detail: the
> beauty of a spreadsheet is that I never worry about who I have to tell
> when I change, the software tends to that automatically, nor do I have
> to step back from writing my formula to do explicit stuff (as in a
> subscribe/notify pattern) in order to get updated -- I just write my rule.
>
> Same with Cells.
>
>>
>> I would suggest the metaphor of a spreadsheet, but that has actually
>> been resoundingly and repeatedly demonstrated as insufficient to make
>> the point.

But we cellsers won't give up on it:

http://pypi.python.org/pypi/Cellulose/0.2

Cells begat PyCells, PyCells begat Trellis and Cellulose. So there are
three Python implementations of Cells now, tho I have a feeling PyCells
is moribund. Cellulose gets a lot of downloads, I think because it is
used in something else. Not sure how Trellis is doing.

kt


--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

On Sat, 24 May 2008 21:48:50 +0200, Frank Buss <fb@frank-buss.de>
wrote:

>George Neuner wrote:
>
>> You're also getting too caught up in the communication abstraction.
>> The book's "information packets" are nothing more than the logical
>> "wires" connecting the functional units of the application.
>
>I think this is wrong, because the information packets are the data, which
>are traveling through the connections.

Not exactly ... the "control IPs" are not application data but
commands to start/stop processes and make/break connections. Thus
control IPs at least are logically part of the wiring of the
distributed application. I suppose it's debatable.

Right now I class FBP as interesting rather than really useful. My
first impression upon reading the book is that the author[*] hasn't
adequately addressed program scaling complexity. From what I can see,
FDP programs will be at least as complex as MP programs.
[*] I'm unsure of the author's surname. Being a stupid American, the
name "van Nostrand Reinhold", as written, looks strange. Google
didn't help. My Anglish guess would be "Reinhold van Nostrand" but I
wouldn't dare to state it as if I really knew.



The elements of FBP are similar to Carriero and Gelernter's Linda
system (the author admits this). The major difference is that FBP
seems to be designed as a rather traditional distributed component
scheme that requires explicit process creation and IPC connections
between components. The components of a Linda application communicate
via a (logical) shared scoreboard maintained cooperatively by Linda
servers. Linda processes and connections are created implicitly by
naming them as data sources or sinks, and lightweight processes can
migrate between servers (Java-Linda makes this particularly effective
because servers can exchange bytecode even in heterogenous networks).

Existing Linda implementations don't scale physically as well as MP
does and FBP might, but Linda's programming model is completely
ignorant of the number of CPUs. Server implementation permitting, the
same Linda program code will run unchanged on any number of processors
and transparently exploit any component parallelism in the
application.

George
--
for email reply remove "/" from address