Thomas F. Burdick wrote:
Kenny Tilton writes:
So the generator sits there trying different values, with nested generators each working thru their values? The generator needs to be able to keep track of where it is between evaluations, including knowing when it is starting a fresh search (if you will).
Yep. I'm envisioning a generator doing things like producing permutations or counting or working its way through a database cursor. Knuth will be useful here. I'm thinking a generator has an internal state which is initialized by a rule, but can be set by the generator's formula. In the case where the generator is reevaluated because something under it FAILed, the state is not reinitialized.
Are you up to speed on the new propagation scheme, as featured most prominently in "unfinished-business"? I guess teh good news is that propagation to dependent cells completes before any output is done, so you do not have to back out outputs (and rules are not supposed to have side effects, tho I did just that in the Dwo Jones use case <gasp>.).
Yeah, the new propagation scheme is really the reason I thought of doing this in Cells itself; it should make it easier to handle at the Cells level.
BTW, have you considered simply leaving Cells out of the logical computation? Just have a classic proplog-in-lisp work things out and produce an aggregation of values from which Cells simply look up the value decided for them? OTOH, I can see how, if you are using Cells, you would just as soon go on using them and then add a little logic, rather than end up with some of the system specified in Cells and some of it specified in some alternative scheme -- especially since the rules in the alternative scheme would tend to have dependencies on Cells. I am talking myself into your approach, but I just wanted to make sure there is not a better way than Cells.
kt
ps. I have to head out for some R&R, but will look at propagating on the stack instead of via the ufb-queue when I get back. k