[Fwd: Re: [cells-devel] Logic Programming in Cells]

[Kenny Tilton]

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