If your Prolog-in-CL uses slot readers/accessors, dependencies will arise. So the position (or whatever GUI layout attribute you have in mind) can be calculated by a cl-prolog operating over CLOS instances via CLOS slot accessor GFs, and the necessary dataflow will arise naturally.
The invocation of the cl-prolog computation will have to require dynamic insertion of initializing/configuring facts. The cell rule calculating the result will specify these facts from other cell values, and supply the calculating form. This then neatly embeds Prolog within Cells, with the Prolog both driving and driven by Cells. Yet one gets (I presume) the greater performance from a dedicated prolog working on a fixed set of facts (for the duration of a single calculation).
Not very sure of the above, btw.
kenny
As an aside, any Prolog implementation needs a good unification routine.
Now, you also want a good unification routine that does CL objects properly.
So you cannot help but using the CL-UNIFICATION package from http://common-lisp.net/project/cl-unification
I know it is a shameless plug, but you simply cannot avoid it :)
Cheers -- Marco
On May 26, 2005, at 12:20 AM, Kenny Tilton wrote:
If your Prolog-in-CL uses slot readers/accessors, dependencies will arise. So the position (or whatever GUI layout attribute you have in mind) can be calculated by a cl-prolog operating over CLOS instances via CLOS slot accessor GFs, and the necessary dataflow will arise naturally.
The invocation of the cl-prolog computation will have to require dynamic insertion of initializing/configuring facts. The cell rule calculating the result will specify these facts from other cell values, and supply the calculating form. This then neatly embeds Prolog within Cells, with the Prolog both driving and driven by Cells. Yet one gets (I presume) the greater performance from a dedicated prolog working on a fixed set of facts (for the duration of a single calculation).
Not very sure of the above, btw.
kenny
-- Cells? : http://www.common-lisp.net/project/cells/ Cello? : http://www.common-lisp.net/project/cello/ Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd
cells-devel site list cells-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel
-- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A.
Marco Antoniotti writes:
As an aside, any Prolog implementation needs a good unification routine.
Now, you also want a good unification routine that does CL objects properly.
So you cannot help but using the CL-UNIFICATION package from http://common-lisp.net/project/cl-unification
I know it is a shameless plug, but you simply cannot avoid it :)
Shameless but well timed, I hadn't realized that your cl-unification goes through slot accessors. Very nice.
Just to dispell any illusions, I'm not trying to turn Cells into a Prolog interpreter. I kind of want a Real Constraints system, but know the problems associated with that, so I'm just playing with trying to mix a little LP into Cells to see if I can get something where my code is a little clearer than what I could get otherwise.
The other motivation is that, in the past, I've had situations where I got data out of a database, and fed it line-by-line into a c-input until I got a consistent model, like:
(do-results (x y z) (db (generate-query a b c)) (setf (values (x obj) (y obj) (z obj)) (values x y z)) (when (model-is-good obj) (return obj)))
I'd prefer to be able to integrate this into the model, so I could have something more like:
(defmodel my-model () ((a :initform (c-input () ...) :accessor a) (b :initform (c-input () ...) :accessor b) (c :initform (c-input () ...) :accessor c) (xyz :initform (c-generator ((it (db-query-iterator *db* (generate-query (^a) (^b) (^c))))) (if (more-tuples-p it) (next it) (fail))) :accessor xyz) ... x y and z here depend on xyz, and if something is inconsistent in the model, their formulas call fail instead of causing (^model-is-good) to be nil ... ))
On May 26, 2005, at 12:20 AM, Kenny Tilton wrote:
If your Prolog-in-CL uses slot readers/accessors, dependencies will arise. So the position (or whatever GUI layout attribute you have in mind) can be calculated by a cl-prolog operating over CLOS instances via CLOS slot accessor GFs, and the necessary dataflow will arise naturally.
Yeah, it could be that some Allegro Prolog enhancements would handle all of this as well. But in the cases where I just want a *little* Logic, making Cells handle it might not be a bad idea. Certainly what I have is entertaining.
Now to look at your recent changes, and to actually restore the old dependencies on backtracking.
On May 26, 2005, at 2:43 PM, Thomas F. Burdick wrote:
Marco Antoniotti writes:
As an aside, any Prolog implementation needs a good unification routine.
Now, you also want a good unification routine that does CL objects properly.
So you cannot help but using the CL-UNIFICATION package from http://common-lisp.net/project/cl-unification
I know it is a shameless plug, but you simply cannot avoid it :)
Shameless but well timed, I hadn't realized that your cl-unification goes through slot accessors. Very nice.
Yep. That was the whole point of the exercise.
In the next version you will be able to do something like
(unify #T(protocol t count-elements ?c get-minimum ?m) #S(tree <list of semi-opaque slots>)) or (unify #T(protocol enum:enumerations current ?x next 42) #<ENUMERATION ....>)
where TREE can be manipulated by the functions COUNT-ELEMENTS and GET-MINUMUM and ENUMERATION, NEXT and CURRENT are part of the (shameless plug) CL-ENUMERATION library for common-lisp.net.
Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A.
Kenny Tilton writes:
Thomas F. Burdick wrote:
Now to look at your recent changes, and to actually restore the old dependencies on backtracking.
Ouch, hadn't thought of that one. And the pulse-stamp, and.... have fun. :)
And the pulse-stamp. Ay.
So, for the moment, I've made a new system: KNOB (KNowledgeable OBjects). In the world of KR, Cells, Cosi, etc, it's a one-trick pony that does targeted backtracking. If it turns out to be a good idea, I'll try to incorporate KNOB-style backtracking (whatever that turns out to be) into Cells. In the meantime, it's a lot easier to make changes to a 300-line, non-industrial-quality object system :-)
Actually, I think I've found an interesting design space. At least it's interesting to me, and lets me express some problems nicely yet efficiently that I couldn't with either Cells nor KR nor Prolog. But I'm still working it out, so integrating it into Cells will be left for a time when I have more confidence in my approach.
Thomas F. Burdick wrote:
Kenny Tilton writes:
Thomas F. Burdick wrote:
Now to look at your recent changes, and to actually restore the old dependencies on backtracking.
Ouch, hadn't thought of that one. And the pulse-stamp, and.... have fun. :)
And the pulse-stamp. Ay.
So, for the moment, I've made a new system: KNOB (KNowledgeable OBjects).
Great name, justification enough for the project. :)
In the world of KR, Cells, Cosi, etc, it's a one-trick pony that does targeted backtracking. If it turns out to be a good idea, I'll try to incorporate KNOB-style backtracking (whatever that turns out to be) into Cells. In the meantime, it's a lot easier to make changes to a 300-line, non-industrial-quality object system :-)
Boy, I can imagine. But tell me you are at least using CLOS!
Actually, I think I've found an interesting design space. At least it's interesting to me, and lets me express some problems nicely yet efficiently that I couldn't with either Cells nor KR nor Prolog. But I'm still working it out, so integrating it into Cells will be left for a time when I have more confidence in my approach.
Sounds neat.
kenny
For what it's worth, you might want to look at Jeffrey Siskind's SCREAMER, which provides nondeterministic programming (with backtracking) for Common Lisp. Of course, this does not include objects, but it would probably be worth a cross-reference.
best, r
-
Kenny Tilton -
Marco Antoniotti -
rpgoldman＠real-time.com -
Thomas F. Burdick