Joerg Hoehle wrote:

Kenny Tilton ktilton@nyc.rr.com writes:

...

But no user has ever indicated they could not figure out how to program with Cells, despite the absence of documentation.

Well, me, and I've casually listened to cell-speak since the days where it was called semaphors and Kenny Tilton was still aiming at enlightment :) -- Now K.Tilton is going to Killton me.

More concretely, I did not groked the concept of "be". To be or become, that is the question.

And Kenny refused to answer your question when you emailed him? The bastard!

More precisely, I think I understand the abstract requirement, as it's nothing new and seen in many places, e.g. the separation between constructing parts of pipeline, clunging it together and finally have something flow through the pipes, but the spare explanations in what doesn't want to call itself cells documentation confuse me more than help.

Well, the problem is making the quantum leap from not being in the dataflow to being in the dataflow all at once. Some background:

One of the nice things about Cells is that the models which are driven by them can vary in population without worrying much about those transient moments when the model is only partially constructed or destructed. For example, I can add instances A and B to the model, where A has a slot with a rule which asks B for a slot with a rule which asks A for a different slot value, and everything Just Works. This is possible because of a certain JIT, on-demand quality of Cells, and because entry or exit from the model by any given instance is managed by to-be and not-to-be.

There is (or was) even some code in the internals that gave special handling to the crucial "kids" slot of the Family class, which is what I always use to build complex models. I think advances in Cells II obviated the need for that special handling. I also think the special handling of the kids slot /outside/ the internals should be generalized so other slots with the same model-extending semantics can be easily defined by non-expert users.

The main idea behind to-be is (a) taking care of initialization required by Cells internals and (b) getting an instance across that quantum leap from not being in the flow to being in the flow.

re the latter, suppose I push a new model instance onto the KIDS of some Family instance in a working model. The idea behind Cells is automatic state consistency, but we now have an instance whose rule-mediated slots are unbound, and whose slot values, once calculated, have not been manifested outside the model by any "output" methods which may exist.

to-be takes care of evaluating ruled slots and outputting all cell-mediated slots.