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