Peter Hildebrandt wrote:
> Ken Tilton wrote:
>>
> Stupid me. Now I remember us talking about it on cells-devel. I will
> dig it up at integrate it with cells-ode next week.
>>
> As a matter of fact, that is what I do. The GUI provides me with a few
> spin-buttons to select how often to run ODE, how often to redraw OpenGL,
> and how often to process the output.

Nice. I was wondering if there would be some way to leverage synapses to
automatically and selectively tune how often the ODE side got polled.
There would be a base rate (perhaps no more frequent than the highest
frequency required by any Cell) and then individual Cells or groups of
cells or something could decide which subset of the base rate samples to
process: Ah, not much is going on, let's wait 10ms before recomputing.
The cool thing would be that the synapse could adjust this over time, so
if things did get crazy up goes the sampling rate.

> But this is all for academics
> anyway, so who is ever going to care?

Academics!? Omigod!! If I had known that...
>>
> Yep. Before starting to work with ODE I seriously considered writing my
> own physics engine and realized quickly that it was not as easy as it
> looks. It is quite simple to get the toy examples right, but once you
> face Real Problems it gets ugly. You find yourself dealing with numeric
> stability, numeric performance issues, optimization here and there,
> borderline cases ...
>
> Decided I could imagine nicer things to do on a sunny afternoon.

Exactly. As long as ODE offers value it is more useful and fun to add
value elsewhere.

>>> Must be nioe having the finish line in sight. Good luck with that.
>> Thanks. And as a matter of fact, it was the best decision of the past
> year or so to set an ultimate deadlide for delivery. I suggest you do
> something similar for you Algebra software. It has a wonderful way of
> focussing the mind :-)

Yep. I went into final approach about six weeks ago, committed to doing
the absolute minimum to have something in folks' hands by, oh, July 1.
It's a lot more fun programming when I can get to something tricky and
just say f**k it, they'll live. :)

kt

Ken Tilton wrote:

> Yep. I went into final approach about six weeks ago, committed to doing
> the absolute minimum to have something in folks' hands by, oh, July 1.
> It's a lot more fun programming when I can get to something tricky and
> just say f**k it, they'll live. :)

If you want to put your mouth where your foot is:

http://www.kalzumeus.com/2008/05/27/...30-day-sprint/

That is my official invitation to you.

Really. Would love to see you reach the finish line.

Sohail Somani wrote:
> Ken Tilton wrote:
>
>> Yep. I went into final approach about six weeks ago, committed to
>> doing the absolute minimum to have something in folks' hands by, oh,
>> July 1. It's a lot more fun programming when I can get to something
>> tricky and just say f**k it, they'll live. :)
>> If you want to put your mouth where your foot is:
>
> [..]
>
> That is my official invitation to you.

Why thank you. I'll think about it. But my experience has been that I
need to minimize distraction ruthlessly, so I might have to pass. Sounds
like fun, tho.

>
> Really. Would love to see you reach the finish line.

Not to worry, I have a friendly letter here from the IRS asking when
they might expect to see last year's taxes, those tend to focus the mind
wonderfully as well. :)

kt

Ken Tilton wrote:

>> Really. Would love to see you reach the finish line.
>
> Not to worry, I have a friendly letter here from the IRS asking when
> they might expect to see last year's taxes, those tend to focus the mind
> wonderfully as well. :)

Well, best of luck focusing. Though I hear lots of (((())))) make you
cross-eyed.

Ken Tilton wrote:
> Nice. I was wondering if there would be some way to leverage synapses to
> automatically and selectively tune how often the ODE side got polled.
> There would be a base rate (perhaps no more frequent than the highest
> frequency required by any Cell) and then individual Cells or groups of
> cells or something could decide which subset of the base rate samples to
> process: Ah, not much is going on, let's wait 10ms before recomputing.
> The cool thing would be that the synapse could adjust this over time, so
> if things did get crazy up goes the sampling rate.

That'd be really nice. Then of course we'd have to intertwine the
stepping function with cells, so that cells knows when it was called the
last time (and with which step size and with how many iterations).
Then a synapse would know when (at which data pulse) it was updated the
last time and how much simulated time had passed since. I believe the
fire decision should be a function of those two.

> Yep. I went into final approach about six weeks ago, committed to doing
> the absolute minimum to have something in folks' hands by, oh, July 1.
> It's a lot more fun programming when I can get to something tricky and
> just say f**k it, they'll live. :)

Great. I'm looking forward to seeing it released :)

Peter

> From: Frank Buss <f>
> ... I think it would be interesting for some people of this
> newsgroup to summarize the concepts of Flow-Based Concepts (FBP),
> compare it to Cells and what we can learn from it.

Is either of them of any value whatsoever in the first place?

> If you like to read some of the basic concepts yourself, take a
> look at
> [..] for FBP

... flow-based programming (FBP) is a programming
paradigm that defines applications as networks of "black box"
processes, which exchange data across predefined connections by
message passing. These black box processes can be reconnected
endlessly to form different applications without having to be changed
internally. ...

This sounds like bullshit. What really is "message passing"?
How is that any different from a function (procedure) being passed
a message consisting of parameters and returning a message
consisting of a set of return values?
Surely two black boxes can't pass messages directly between them,
because neither can possibly know of the other's existance. Some
higher-level controller must decide which message is to be passed
to which black box and then collect whatever return messages it
produces and decide where to forward them next.
So I don't see how FBP is any different from procedural programming,
where a main application calls the various subroutine components.
If a subroutine component needs to return more than one set of
return values, some immediately and some later, then all we need to
arrange is that it returns a set of two return values, one of them
the bundle of immediate return values, and the other a
continution which will be automatically called again.

... a network of
asynchronous processes communicating by means of streams of structured
data chunks, called "information packets" (IPs). ...

That doesn't require anything more than multi-processing procedural
programming. Whenever you call a function (procedure) which returns
both a bundle of immediate return values and a continuation, you
fork the process to handle each separately in parallel. Whenever
the controller needs to send some return values to one procedure
and other return values to another procedure, again the controller
needs only fork the process and run the two forwardings in
parallel.

What if a procedure needs several different inputs from different
sources before it will be ready to return some values? That's easy
in procedural programming too: All you need is an OWN (static)
variable that keeps the internal state from one call to the next,
and a NULL type of return that is simply discarded, in a case where
there are no return values yet. (It's these NULL return values that
cause a decrease in the total number of processes running in
parallel. Otherwise the number of processes would keep increasing
any time there's a fork due to returnValues+contiuation or
returnValues to more than one destination.)

> More than one process can execute the same piece of code.

So each instantiation of the same piece of code is working with a
different instance of the OWN variable containing the interal
state, right? So presumably the controller creates new instances of
each piece of code, each with a virgin interal state, and then
subsequent calls to that piece of code with *different* sets of
parameters would cause the no-longer-virgin internal states to be
different in content, right?

In a language like Java, the different instances of internal state
for the same piece of code could be emulated by using an instance
variable. To start a new instance of code+state, you call a
constructor, which returns an object with one internal field, the
state. Then you make a method call using that object, which updates
that state before returning. CLOS could do something similar.

The network definition is usually diagrammatic, and is converted into
a connection list in some lower-level language or notation. FBP is
thus a visual programming language at this level. ...

This sounds like more bullshit. It's the GUI which is diagrammatic.
The *actual* network definition is a connection list, which is
somewhat hidden from view when using the GUI, but it's really there
all the time, and it's quite apparent when writing "programs that
write programs", as is often done in Lisp. It would be a royal
pain, when writing a program that writes a FBP program, to need to
convert all the details into a visual diagram (or mouse motions to
draw a visual diagram) which is somehow fed back into the GUI.
I remember programming in HyperTalk like that. For example, a
script to create a button would read somewhat like this:
FUNCTION MakeButton(x1,y1,x2,y2,newname)
choose the button tool;
move the mouse to x1,y1;
drag the mouse to x2,y2;
choose the select tool;
select the chunk at (x1+x2)/2,(y1+y2)/2;
set the name of the selected chunk to newname;
END MakeButton;
(Take the precise syntax with a grain of salt. The main point is
that there's an interactive editor for building a GUI by installing
buttons etc. into the drawing pane, whereby certain menu actions
are needed to get into and out-of button-mode, and certain mouse
motions within button-mode are needed to create a new button, and
from a script you meticulously describe those menu+mouse actions
to accomplish the same GUI effect.)

... IPs traveling across a given connection
(actually it is their "handles" that travel) constitute a "stream",
which is generated and consumed asynchronously ...

So that pretty much precludes running such a process on multiple
CPUs connected across the InterNet? Or does a process on one
machine owning a handle for data on another machine have a way to
request that other machine to eventually send the actual data?
(What does Java call that? It's been a while. It's more than just
RMI+SOAP+JNDI. But I forget the name. It's related to Enterprise Beans?)

... The task, called the "Telegram Problem", originally
described by Peter Naur, is to write a program which accepts lines of
text and generates output lines of a different length, without
splitting any of the words in the text (we assume no word is longer
than the size of the output lines). ...

This isn't well specified. It leaves some important facts unstated.
For example, are all the lines of input given at the start, and the
program has access to them all before needing to start working on
the first output line? Or are the lines of input given
incrementally and a line of output should be generated as soon as
there's enough data from input to be sure that no more words will
need to be added to the currently-getting-built line of output? Are
the lines of input given in gulps, a whole line as an atomic input,
or are the lines of input given character by character?

> and [..] for Cells.

... analogous to a spreadsheet cell (e.g. --
something in which you can put a value or a formula and have it
updated automatically based on changes in other "cell" values).

That's a rather limited framework for developing applications.

> Anyone interested in implementing FBP in Lisp?

Do you mean implement it in some particular vendor-supplied
implementation of Lisp which happens to support multiple threads?
Or somehow implement it in ANSI CL, somehow emulating threads by
means of some sort of polling loop?


-
Nobody in their right mind likes spammers, nor their automated assistants.
To open an account here, you must demonstrate you're not one of them.
Please spend a few seconds to try to read the text-picture in this box:

/----------------------------------------------------------------------------\
~|~ |` _ _ _ _ _ _ _ _|. _ _ _|_|_ . _ ._|_|_ _ _|_
_|_~|~ \/(_)|_| (_|| (/_ | (/_(_|(_||| |(_| | | ||_\ VV| | | |(_)|_| |
/ _|
_| _ _ _ _ _|_. _ _ ._|_ |`. _ __|_ _ _ _ _ _ _|_|_ . _ _ . _
(_|(/_(_| \/|_) | || |(_| | | ~|~|| _\ | , _\(_)| | |(/_ | | ||| |(_| |_\
/ | _| _|
_ _ _ _ ~|~~|~ |~\~|~|~\|\ |'~|~ /~`/~\|\/|(~ |~|~)/~\|\/| |\/|(~|
VV| (_)| |(_|. _|_ | |_/_|_|_/| \| | \_,\_/| |(_ |~|~\\_/| | | |(_.
_|
\----(Rendered by means of <http://www.schnoggo.com/figlet.html>)------------/
(You don't need JavaScript or images to see that ASCII-text image!!
You just need to view this in a fixed-pitch font such as Monaco.)

Then enter your best guess of the text (50-150 chars) into this TextArea:
+------------------------------------------------------------+
| |
| |
| |
| |
+------------------------------------------------------------+

Peter Hildebrandt wrote:
> Ken Tilton wrote:
>>
> That'd be really nice. Then of course we'd have to intertwine the
> stepping function with cells, so that cells knows when it was called the
> last time (and with which step size and with how many iterations).

Search on "f-sensitivity". :) The synapse does all the work, including
keeping track of the last time it fired. But then the question is
whether that work is more expensive than Just Firing, or so expensive as
to produce little gain. Steele started by having variable assignment be
a constraint in his CPL (the classic All X All the Time error, aka the
"Hey! Let's use it for /everything!" error) and soon enough found out
how slow slow could be. If so, as you suggested we extend Cells a little
to support some "hard-wired" dataflow that bypasses the Cells machinery.

kt

Robert Maas, http://www.rawbw.com/~rem/WAP.html wrote:
>> Is either of them of any value whatsoever in the first place?
>>
>
> ... flow-based programming (FBP) is a programming
> paradigm that defines applications as networks of "black box"
> processes, which exchange data across predefined connections by
> message passing. These black box processes can be reconnected
> endlessly to form different applications without having to be changed
> internally. ...
>
> This sounds like bullshit. What really is "message passing"?
> How is that any different from a function (procedure) being passed
> a message consisting of parameters and returning a message
> consisting of a set of return values?

The rest of what you wrote also makes sense in a similar vein, but it is
tantamount to looking at Lisp and asking (an extreme case) how it is any
different than a Turing machine. The question confuses theoretical
equivalence with the programmer experience -- the mechanisms may be
inter-transformable where the programmer experince is not.

As for how is the programmer experience different with other paradigms,
it seems to me some people can look at small examples of something new
like FBP or OO or Prolog and Just Get It, other people do not. The ones
who get it may not end up /liking it/, but that would be after giving it
a try, again without bringing a lot of emotional baggage to the table
like "how is this different?" and "why should I learn it?".

Hey, it's just a tool, relax.

Early adopters are always looking for new toys and they tend to be
brighter than average and have a lot of confidence that they can browse
one or two pages of info and "get it (or not)" so they do. While they
browse there is this huge suspension of disbelief because they
understand the new toy will seem weird at first and that they themselves
are creatures of habit so "ya gotta give it a chance".

Consider structured programming. Sure, no different! Not. For the
programmer, all the difference in the world is had just from limiting
oneself to a tight subset of constructs possible. Those of us who were
open to it really enjoyed it once we lived with it. I remember the
epiphany I had when I realized I could look at my program doing
something daft and know for a fact which branch in the code had been
taken, telling me all the things that must be true for me to have gotten
there (which conditional branches had been followed, which flags were in
which state, etc etc). That was so cool, let alone the fact that there
were so many fewer bugs to find. Again, the programmer experience: work
and effort got shifted from the expensive tailend debugging phase to the
cheaper design/planning phase /by the paradigm/.

Likewise with Cells, one is compelled to put all the logic to determine
a slot of an instance in one lexical chunk of code. That very discipline
turns out to be empowering, part of why I am down on the many backdoors
in KR: the power lies to some degree precisely in the absence of backdoors.

If you read the stuff on FBP, you will find one of its advocates talking
about the same discipline forced on programmers to translate their usual
imperativethink into flowthink. The good news is that this is actually
quite fun and offers the Golden Trade-Off: think harder on more
interesting problems to avoid massive amounts of tedious mind-numbing work.

hth,kt

On May 23, 4:30 pm, Frank Buss <f> wrote:
> I've read nearly half of the book [..]
> from the page [..]

I read all of it, some 13 years ago.

> FBP is very different: When developing applications, you start with
> defining information packets (IP). In Lisp an IP could be a hashtable or
> any other Lisp object. Then you define some processes and interconnect
> them. A process has inputs and outputs for processing IPs. The process
> itself is a program, with local storage.

Where storage constitutes state!

> A process can be instantiated
> multiple times and can be configured with configuration IPs (there are
> preemptive and cooperative multitasking implementations).

I worked on some projects which incorporated these FBP concepts, and
realized it's a mess. FBP sounds good on paper, but it's
``impossible'' to debug.

If something goes wrong---for instance, a process obtains bad data
from somewhere---you don't have a useful call trace. The top of your
thread called some ``getmessage'' function, which pulled the bad
message from a queue where it was deposited by another thread that has
since gone on to do other things.

If you've ever debugged a communication protocol, you know what I
mean.

You're going to end up with silly abstraction inversions. Programmers
will want simple function calls, and they will emulate them by
defining information packet types which are like functions. The
configuration IP concept in FBP is a perfect example of this. You just
want to call a simple function with arguments to configure a process
(ideally, just once via a constructor call), but instead, you have to
instantiate a process, hook it into this network, and send it a
packet.

The nice thing about functions is that the caller is suspended until
the function returns, and the caller synchronously collects the return
value. You can set breakpoints, single-step the entire process if
necessary, and view the activation chain.

Also, did you get to the part of the book where it describes very
stateful processes which, for instance, parse nested syntax? It even
uses Lisp notation. What happens if the stream of packets being parsed
by some process has a syntax error? Ah, right. FBP applications
consist of debugged processes, so that would never happen in the
field. :)

> According to the book, at IBM they have successfully used it
> in many projects and one example with three projects, in the third project
> they achieved a reuse rate of about 97% (PDF pages 42/43 in the book).

A reuse rate of 97% means that you really don't have a new project.
You just tweaked something in the existing project and /called/ it a
new project.

If your ``new'' project has 97% of the code of the ``old'' one, you've
only done a minimal amount of new work. This could only be because the
requirements have only changed in a trivial way.

Or it could also be that 97% of your effort was spent in developing
infrastructure whose details are irrelevant to the problem domain. If
Common Lisp is 99 times bigger than the average program you write,
then each time you write a new program, you can claim 99% reuse. :)

Robert Maas, http://www.rawbw.com/~rem/WAP.html wrote:

> This sounds like bullshit. What really is "message passing"?
> How is that any different from a function (procedure) being passed
> a message consisting of parameters and returning a message
> consisting of a set of return values?

The difference is : synchronization.

Re-read what you wrote above - it reveals the dogma of synchronization.

A function/procedure passes a message, then returns a set of values. All
the while that the function/procedure is running, the caller is stalled
waiting for an answer (the return), even if it doesn't really care about
the answer.

In message passing (event sending, as I prefer to call it), the caller does
not wait for a response. You cannot do that with function calls unless you
invent cumbersome extraneous baggage (e.g. an rtos or an event loop or the
utterly insane concept of rpc's).

In reactive programming, NOTHING is synchronized unless the programmer makes
it so.

In call-return programming (functional, procedural, etc) EVERYTHING is
synchronized - always.

People are currently wracking their brains trying to figure out how to
program multi-core cpu's. They think that it's a hard problem. But only
because they cannot think outside of the call-return box. Same thing
happened in the early Windows days - people had 6-month learning curves
before they could produce even a simple Windows program. That's because
Windows (GUI) programming is a reactive problem and people were trying to
fit anti-reactive programming languages and thinking onto the problem
space. Same with network protocols.

Do you happen to know anything about hardware design? TTL, say. On a
circuit board populated with TTL chips, are the chips all synchronized or
are they asynchronous? Do hardware people achieve better success rates in
their designs than software people do in their designs?

Do chip designers offer some kind of guarantee that their chips will work as
specified in the data sheets?

Do software designers offer equivalent guarantees?

pt

Kaz Kylheku wrote:
> On May 23, 4:30 pm, Frank Buss <f> wrote:
>>
> I read all of it, some 13 years ago.
>>
>
> Where storage constitutes state!
>>
>
> I worked on some projects which incorporated these FBP concepts, and
> realized it's a mess. FBP sounds good on paper, but it's
> ``impossible'' to debug.

Cells has issues that way, esp. since I shifted to a queue structure to
handle propagation so you don't have a call stack to follow when you
land in the debugger, but only rarely do I have a problem involving
"hey, why am I recalculating?". The whole point of declarative
programming is to write rules that cover all the cases by calling on all
the input they need, so all I need to know to debug a rule are my
inputs. If I see a crazy input, Tilton's Law cuts in and I go worry
about that Cell.

But, yes, the paradigm shift does introduce some issues.

>
> If something goes wrong---for instance, a process obtains bad data
> from somewhere---you don't have a useful call trace. The top of your
> thread called some ``getmessage'' function, which pulled the bad
> message from a queue where it was deposited by another thread that has
> since gone on to do other things.
>
> If you've ever debugged a communication protocol, you know what I
> mean.
>
> You're going to end up with silly abstraction inversions. Programmers
> will want simple function calls, and they will emulate them by
> defining information packet types which are like functions.

And this is why we love a multi-paradigm language. Things like FBP and
Cells should be used selectively within the code beast. Unfortunately
the usual reaction people have when they hit on something new is "Hey,
let's make a new language." They missed Tilton's Law:

Make new datatypes, not new languages.

kt

Ken Tilton wrote:

> The nomenclature is fine, rather our subjects do not match.

I'm lost. I can't figure out if you're agreeing with me or arguing with me.

So, I'll just change the subject and respond with things that tangentially
fired some of my neurons.

(BTW, if you keep up the veiled political threats, I'll, I'll, report you to
the CSA, exchange all of my canmeros for euros and request that CAARP bring
on a new ice age rendering all oil on the planet to become uselessy
solidified).

> But now we have a different rule that worries about a mouse-down event.
> A button with a slot called "clicked?". But a mousedown /happens/, it
> does not exist. Well, it exists ephemerally -- its existence is also its
> demise.

Yes. Events are discrete packets.

Furthermore, a part that fires events from one of its output pins does not
know "where" the event goes. It might go to one receiver or many receivers
or zero receivers.

Yes, a part can fire events to an output pin, even if the pin is NC (no
connection).

[Try that, you call-return people!]

When the launch commander sat down on the launch button, the button fired
off (one) "I'm going down" event. At that point in time, the rest of the
system was in a "don't care" state and the event was unceremoniously dumped
into the Fargo wood-chipper.

> No, I just do not want to /think/ about events or change /while
> programming/. That is a slippery slope that ends up with Brooks being
> right: manual management of change by the programmer is ineluctably hard
> once a too-low threshold of application complexity is reached.

If that's what he actually said, then he's simply wrong. It's only too hard
to manage change (control flow) if you tangle it up with other orthogonal
concerns (e.g. like data design or getting rid of goto's).

OTOH, I do believe that designing notation to fit a paradigm is a good thing
(comes from a physics background). If the target paradigm does not need
events, then they shouldn't be exposed to the user.

I am, though, personally interested in the grand unified theory of
softwaring and that's certainly where I was coming from.

> The trick then -- and hey, maybe I missed an easier way! -- is that

Maybe.

I once built a injection-molding control language which allowed for "active"
variables inside expressions (akin to what I think Cells does). I needed
to build the compiler using 8 passes just to keep things straight in my
mind and to calculate the global dependency chains.

After completing that exercise, I stepped back and noticed a "pattern" which
eventually turned into a simple event-shepherding kernelette and truly
encapsulated doo-dads (parts) that simply potato-gunned discrete events at
each other.

> As for there being an easier way, perhaps there is a way to duck the
> special handing of events by using time as state

That direction leads to
<upcase><bold><biggest-font>T</upcase></bold></biggest-font>rouble.

Read up on "race conditions" in an electronics text. The Right Way to solve
these problems is to admit that you cannot resolve time with sufficient
accuracy to determine the time-ordering of events. Sometimes 'a' appears
to occur before 'b', sometimes the other way around. There is always a
unit of time smaller than your ability to measure and, hence, there is
always the possibility that you cannot resolve the order of two events.
The Correct Answer is to defensively, explicitly design in
anti-race-condition measures (well-understood and well-documented in
hardware design texts).

pt
Toronto, Canada

Paul Tarvydas wrote:

> We have faked it under Windows (C) and Lispworks. A real project (an IDE
> running under Windows) used something like O(10,000) part instances, iirc.
> A simulation achieved O(1M) instances.

For an embedded system with interrupts this sounds like it is not too
difficult, but how did you do this with Lispworks in Windows? I assume you
don't create 1M threads, which would be really slow.

On Thu, 29 May 2008 11:26:53 -0400, Paul Tarvydas
<tarvydas> wrote:

>Do you happen to know anything about hardware design? TTL, say. On a
>circuit board populated with TTL chips, are the chips all synchronized or
>are they asynchronous?

TTL is not asynchronous in the manner that software people generally
use the term.

In an unclocked design each part is slaved to the part(s) that provide
input to it. Any directed web of TTL logic is synchronous relative to
stability of its input - the propagation time to produce a result once
input stabilizes is predictable. The only really independent circuits
are loops with no external inputs - such as fixed frequency
oscillators - and even then the individual TTL components of the macro
loop circuit are themselves synchronous relative to one another.

A hardware analogy more in keeping with a software discussion would be
two incompatibly clocked macro parts with handshaking data transfer
between them.


>Do hardware people achieve better success rates in
>their designs than software people do in their designs?

Yes. But the reason is because they don't invent new logic but simply
reuse standardized components having known behaviors. Even when the
components are interconnected in novel ways, the behavior of the
result is predictable.


>Do chip designers offer some kind of guarantee that their chips will work as
>specified in the data sheets?

No. They offer "warranty" ... which is a very different concept from
"guarantee".


>Do software designers offer equivalent guarantees?

No. But some select few do offer warranty.

George

On Wed, 28 May 2008 02:51:16 -0400, Ken Tilton wrote:

> As for there being an easier way, perhaps there is a way to duck the
> special handing of events by using time as state (with Lisp time
> granularity then being sufficiently imprecise as to take out Canada on
> an unlucky day) but Tilton's Laws of Programming frowns on making things
> more complicated in order to make things simpler: if a mousedown is not
> like a mouse position they should be different in the same way.
>
> peace, out, kzo

you could just have a multi step process

button = cell tied directly to the mouse (like a volatile variable in C)
this one receives information from the mouse just like the other example
received the temperature. it's mostly a proxy, it passes on its contents
whenever they are received to the switch which actually makes the decision.

the key here is that mice send nothing when nothing CHANGES.

switch = cell which either points to nowhere or to another cell
when up is received it points to nowhere
when down is received it points to the cell that does the processing

the reason for the switch between limbo and work is that if the button is
held down and some other event needs to know then the switch can be
querried for the cell to go to rather than trying to beg the mouse to
report.

essentially Cells needs transistors.

Or you could get physematical:
Every cell can have up to the umpteenth derivative.
State, Change, Acceleration, Jump, Flash, Sneeze
each could be tied to a cell