[cl-unification-devel] copy-env

[Gavin Mendel-Gleason]

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 at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cl-unification-devel
>