rpgoldman@real-time.com wrote:
"KT" == Kenny Tilton ktilton@nyc.rr.com writes:
KT> Thomas F. Burdick wrote:
Kenny Tilton writes:
(b) eliminate the check for looping in which one setf of a cell leads back to setf of the same cell (the scroll bar scenario). I will leave the code behind in case I decide to simply enhance cycle detection as opposed to wiping it out entirely.
I think The Right Thing is to allow looping by default, assuming that the programmer knows what they're doing,
KT> done.
and to be able to optionally declare a certain cell to be non-cyclic
KT> for debugging? ie, How are non-cyclic cells to be handled?
Perhaps I'm missing something, but I would have thought that cyclic cells would have been the unusual case, and the one you want to trap by default. I.e., it would make more sense to default to acyclic, and then allow users to explicitly declare cycles.
Actually, that is the way it has been for ages, and the change just made was to flip the direction of that choice.
Cells now effortlessly run on propagating if the user chooses to set things up that way. And I think that is actually a natural way to program in what we might call a causation paradigm of programming. For now you are right, it is the exception, but I have also been looking at solving certain problems with more of this. But that is not the main issue here.
The fact is, detecting cycles takes extra (Cells internal) code and extra runtime effort, including maintaining a list of "causers" in a given data pulse so as to detect cycles. (Propagation no longer takes place in a call stack, so there is no clear place to set/clear a flag indicating causation is underway.)
The interesting question is not the default value for the cyclicp parameter, should it return to Cells; anyone can override the group choice with their own macros. The question now is simply whether and how to allow the user special syntax by which to control cycling.
kt