[developers] create-wffs(), process-unifications(), and unification contexts

Stephan Oepen oe at csli.Stanford.EDU
Sat Mar 31 07:01:09 CEST 2007

hi john and ann,

a while ago, i stumbled into create-wffs() and process-unifications()
insisting on establishing their own unification contexts.  the latter,
in my view, should never actually require a unification context, as it
(seems to) exclusively operate on fresh dags.  and the former tends to
be invoked on the return value of process-unifications(), hence it can
at times be convenient (and risk-free, i believe) to be able to invoke
both functions, even within an existing unification context.

for just now, i worked around it by adding a new optional parameter:

  (defun create-wffs (fs &optional (contextp t))
      (with-unification-context (fs) (create-wffs fs nil)))

this means the original behavior is preserved, but it becomes possible
to explicitly skip the creation of a new unification context.  i have
applied the same technique to process-unifications(), though i suspect
it actually provides unnecessary protection there.

i am about to check these changes in and would be grateful if you were
to give these questions some thought (this modified code has been used
without problems in LOGON in the past months already).

finally, i just noticed the following in copy-dag1():

  (let (...
        (new-arcs (nreverse (dag-comp-arcs dag))))

with our standard sequence of

  unification context

the above should be unproblematic.  but it does mean that `comp-arcs'
is undefined (given the destructive nreverse()) after the copy().  if
someone were to add another dag operation to the end of that context,
say a subsumption test (in a version ignoring the `copy' slots), then
the above would become an issue.  hence i am tempted to play it safe:

  (new-arcs (setf (dag-comp-arcs dag) (nreverse (dag-comp-arcs dag))))

what do you think?

                                                         best  -  oe

+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at csli.stanford.edu; oe at ifi.uio.no; oepen at idi.ntnu.no ---

More information about the developers mailing list