Hello,
I had the same problem and I don't think it was intentional. I think it is because it is mostly used for deterministic code.
You don't really need to copy everything anyhow if you are using a standard unification algorithm since changes should be monotonic. You just need to branch. You can effect this with the following change:
(defun make-shared-environment (env) (make-environment :frames (environment-frames env)))
=>
(defun make-shared-environment (env) (make-environment :frames (cons (make-frame) (environment-frames env))))
Or some alteration that is similar that branches the environments at choice points.
Gavin
On 12/4/05, norman werner norman.werner@web.de wrote:
Hello
While writing a library with prolog like capabilities on top of cl-unification and a home brewn nondeterministic library I need a way to copy environments.
There is a (internal) function copy-env in cl-unification. So I exported it. The problem is that this function returns a new environment which actually still shares objects with its original argument.
Is this intentional? If not I propose the following (code will certainly contain bug, because i write it from memory only)
(defun copy-env (e) (make-environment :frames (mapcar #'copy-frame (frames e))))
(defun copy-frame (f) (make-frame :bindings (mapcar #'copy-binding (binding f))))
(defun copy-binding (b) (mapcar #'(lambda (cell) (cons (car cell) (cdr cell))) b))
Norman ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
cl-unification-devel site list cl-unification-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cl-unification-devel