[cl-unification-devel] Re: question about CL-UNIFICATION

rpgoldman at real-time.com rpgoldman at real-time.com
Fri May 27 19:58:44 UTC 2005


>>>>> "MA" == Marco Antoniotti <marcoxa at cs.nyu.edu> writes:

    MA> On May 27, 2005, at 2:51 PM, rpgoldman at real-time.com wrote:

    >>>>>>> "MA" == Marco Antoniotti <marcoxa at cs.nyu.edu> writes:
    >> 
    MA> Hi
    MA> thanks for the comments.
    >> 
    MA> On May 27, 2005, at 12:25 PM, Robert P. Goldman wrote:
    >> 
    >>>> 
    >>>> I was following up on CL-UNIFICATION based on your email to the cells
    >>>> list, and read over the web site docs.  I was left with the question
    >>>> of how to unify together two structures or objects.  I see how one 
    >>>> can
    >>>> unify a structure (or object) with a template, and how that might be
    >>>> used for ML-style pattern-matching.
    >>>> 
    >>>> But what if you really want to know if two structures themselves
    >>>> unify?  Presumably one might want to do something like the following:
    >>>> 
    >>>> (setf x #S(FOO A 42 S NIL D NIL))
    >>>> (setf y #S(FOO A 42 S NIL D NIL))
    >>>> 
    >>>> where x and y are EQUALP, but not EQ, and you'd like to do
    >>>> 
    >>>> (unify x y)
    >>>> 
    >>>> but this is impossible.
    >> 
    MA> Ooops.  Not good.
    >> 
    >> 
    >> 
    >>>> Is the following correct:
    >>>> 
    >>>> (unify x #T(FOO foo-a (foo-a y) foo-s (foo-s y) foo-d (foo-d y)))
    >> 
    MA> Yes.  This would work.
    >> 
    >> 
    >>>> 
    >>>> and, if so, is there some less cumbersome way to make this happen?
    >>>> I.e., to have a unification method definition that would say 
    >>>> "whenever
    >>>> I unify together a FOO and a FOO, I want to apply this template to 
    >>>> the
    >>>> second argument?
    >> 
    MA> You make a very good point.
    >> 
    MA> Right now, the only defined methods for UNIFY with 
    >> STRUCTURE-OBJECTs are
    >> 
    MA> unify structure-object template
    MA> unify template structure-object
    >> 
    MA> TRT would be to write a method for
    >> 
    MA> unify structure-object structure-object
    >> 
    MA> This would be a limited method in any case, just testing for 
    >> equality
    MA> with EQUALP.  E.g. given
    >> 
    MA> (setf x #S(FOO A ?x))
    MA> (setf y #S(FOO A 42))
    >> 
    MA> (unify x y)
    >> 
    MA> would return an empty environment.  I.e. the unifier would not 
    >> recur
    MA> into the slots.
    MA> In alternative the unifier could generate two subtests
    >> 
    MA> (unify x #T(FOO foo-a (foo-a y) foo-s (foo-s y) foo-d (foo-d 
    >> y)))
    MA> (unify #T(FOO foo-a (foo-a x) foo-s (foo-s x) foo-d (foo-d x)) 
    >> y)
    >> 
    MA> This is needed to ensure cross unifications.
    >> 
    MA> I know I could do away with all of this by invoking 
    >> implementation
    MA> dependent code  getting the structure slots.  But I am kind of 
    >> against
    MA> it.  As it is the unification code is completely portable.
    MA> Yet, given enough pressure, I will concede and add the the
    MA> extra code.
    >> 
    >> Actually, what I had intended was for the programmer to be able to
    >> extend unify along the lines that you were talking about (the pair of
    >> tests for FOO, above).  I agree that this can't be done generally, but
    >> could be made to work in special purpose cases.

    MA> Well, you can extend UNIFY.  Just add methods to the generic function.  
    MA> I believe the basic behavior is documented, so you know where the 
    MA> limits are.

    >> 
    >> The next thing that one might do, it seems to me, would be to write a
    >> metaclass for unifiable structures, wherein one might mark slots as
    >> being intended for use in unification or not, as one chose.  Then if
    >> one wished to make a unifiable class, one could make it of the
    >> unifiable metaclass...

    MA> Yes.  I agree.  But I am not sure you can specify a metaclass for 
    MA> structure classes.

Ah.  A good point.  Perhaps then an extended DEFSTRUCT macros.  I
don't think my earlier email was particularly clear.  What I had in
mind was the ability for the user to easily specify a default template
that could be used in the process of comparing two objects of the same
type.  For structure objects DEFSTRUCT-UNIFIABLE would be one way to
do this, and for CLOS objects a metaclass might be better (accepting
caveats about the portability of the MOP...)

Best,
R



More information about the cl-unification-devel mailing list