- cl-unification-devel - mailman3.common-lisp.net

[cl-unification-devel] CL-UNIFICATION updated
by Marco Antoniotti 13 Jul '08

13 Jul '08

Hi I made a few updates to CL-UNIFICATION. The most important one is that I started a test suite, which has already shown a few pitfalls. The second most important one is that now the #T syntax went back to the original setup, where template instances are built at read-time. This means that (1) nested templates should be working as expected, and (2) probably a new programmatic constructor is needed. The companion MAKE-LOAD-FORM seems to fix the fasl manipulation problems, but you may want to make more tests. Some other bugs and requests for changes did not make it in. Please try the new version, be patient and report bugs. You can download the tarball from the CVS repository. Cheers -- Marco

1 0

Re: [cl-unification-devel] a simpler example
by Russell McManus 12 Jun '08

12 Jun '08

I tried the attached version, and the problem persists. Thanks for looking into it, -russ ----- Original Message ---- > From: Marco Antoniotti <marcoxa(a)cs.nyu.edu> > To: cl-unification-devel(a)common-lisp.net > Cc: Russell McManus <russell_mcmanus(a)yahoo.com> > Sent: Wednesday, June 11, 2008 11:02:56 AM > Subject: Re: [cl-unification-devel] a simpler example > > There may be a misalignment with my version (which works on LW) and > the CVS version, or it may be a problem which SBCL raises due to its > version (more strict) of MAKE-LOAD-FORM. > > I'll look into it. > > Thanks for raising the issue. > > Meanwhile try the version attached on SBCL. > > Cheers > -- > Marco > > > > > > > On Jun 11, 2008, at 16:04 , Russell McManus wrote: > > > I'm pretty sure that I tried repeating the #T before sending my > > first email, but it failed with an error. > > > > I just tried again on sbcl 1.0.10.16 and got the following: > > > > (unify #T(list ?f #T(list ?s1 ?s2)) '(a (b c))) > > > > > > Cannot unify two different symbols: B MAKE-TEMPLATE. > > [Condition of type CL.EXT.DACF.UNIFICATION::UNIFICATION-FAILURE] > > > > Restarts: > > 0: [ABORT] Return to SLIME's top level. > > 1: [TERMINATE-THREAD] Terminate this thread (# > > "worker" {1008AB0C91}>) > > > > Any ideas what I should try next? > > > > -russ > > > > > > > > ----- Original Message ---- > >> From: Marco Antoniotti > >> To: cl-unification-devel(a)common-lisp.net > >> Sent: Tuesday, June 10, 2008 3:51:44 AM > >> Subject: Re: [cl-unification-devel] a simpler example > >> > >> > >> On Jun 6, 2008, at 24:38 , Russell McManus wrote: > >> > >>> > >>> Here are some examples: > >>> > >>> ;; this works > >>> (find-variable-value > >>> '?s > >>> (unify #T(list ?f ?s) '(a (b c)))) > >> > >> Yes. > >> > >>> > >>> ;; this works > >>> (find-variable-value > >>> '?s1 > >>> (unify #T(list ?f (?s1 ?s2)) '(a (b c)))) > >> > >> Yes. > >> > >> > >>> > >>> ;; this fails > >>> (find-variable-value > >>> '?s1 > >>> (unify #T(list ?f (list ?s1 ?s2)) '(a (b c)))) > >> > >> As it should. What you want is > >> > >> (unify #T(list ?f #T(list ?s1 ?s2)) '(a (b c))) > >> > >> In your case you are trying to unify a template of type LIST with a > >> variable in FIRST and a list (LIST ?s1 ?s2) in SECOND. The second > >> element cannot unify with (B C), hence the failure. > >> > >>> > >>> I was expecting the meaning of LIST to be the same whether > >>> it is encountered at top level in a template, or at a nested level. > >>> > >>> Is this a bug, or are my expectations wrong? > >> > >> Sorry. It is your expectations. If you look at the most general > >> syntax for templates, you will see that it is #T(. > >> ). This is because it would be a nightmare to do otherwise. > >> > >> > >> Suppose you have a > >> > >> (unify #T(list 42 (foo)) (list 42 (list 'foo))) > >> > >> should unify. But is next you do > >> > >> (defstruct foo a s d) > >> > >> then > >> > >> (unify #T(list 42 (foo)) (list 42 (list 'foo))) > >> > >> may or may not unify pending interpretation. > >> > >> Hope this clarifies things. Let me know if there are other pitfalls > >> or bugs in the code. > >> > >> Cheers > >> > >> Marco > >> > >> > >>> > >> > >> -- > >> Marco Antoniotti > >> > >> > >> _______________________________________________ > >> cl-unification-devel site list > >> cl-unification-devel(a)common-lisp.net > >> http://common-lisp.net/mailman/listinfo/cl-unification-devel > > > > -- > Marco Antoniotti

2 1

Re: [cl-unification-devel] a simpler example
by Russell McManus 11 Jun '08

11 Jun '08

I'm pretty sure that I tried repeating the #T before sending my first email, but it failed with an error. I just tried again on sbcl 1.0.10.16 and got the following: (unify #T(list ?f #T(list ?s1 ?s2)) '(a (b c))) Cannot unify two different symbols: B MAKE-TEMPLATE. [Condition of type CL.EXT.DACF.UNIFICATION::UNIFICATION-FAILURE] Restarts: 0: [ABORT] Return to SLIME's top level. 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker" {1008AB0C91}>) Any ideas what I should try next? -russ ----- Original Message ---- > From: Marco Antoniotti <marcoxa(a)cs.nyu.edu> > To: cl-unification-devel(a)common-lisp.net > Sent: Tuesday, June 10, 2008 3:51:44 AM > Subject: Re: [cl-unification-devel] a simpler example > > > On Jun 6, 2008, at 24:38 , Russell McManus wrote: > > > > > Here are some examples: > > > > ;; this works > > (find-variable-value > > '?s > > (unify #T(list ?f ?s) '(a (b c)))) > > Yes. > > > > > ;; this works > > (find-variable-value > > '?s1 > > (unify #T(list ?f (?s1 ?s2)) '(a (b c)))) > > Yes. > > > > > > ;; this fails > > (find-variable-value > > '?s1 > > (unify #T(list ?f (list ?s1 ?s2)) '(a (b c)))) > > As it should. What you want is > > (unify #T(list ?f #T(list ?s1 ?s2)) '(a (b c))) > > In your case you are trying to unify a template of type LIST with a > variable in FIRST and a list (LIST ?s1 ?s2) in SECOND. The second > element cannot unify with (B C), hence the failure. > > > > > I was expecting the meaning of LIST to be the same whether > > it is encountered at top level in a template, or at a nested level. > > > > Is this a bug, or are my expectations wrong? > > Sorry. It is your expectations. If you look at the most general > syntax for templates, you will see that it is #T(. > ). This is because it would be a nightmare to do otherwise. > > > Suppose you have a > > (unify #T(list 42 (foo)) (list 42 (list 'foo))) > > should unify. But is next you do > > (defstruct foo a s d) > > then > > (unify #T(list 42 (foo)) (list 42 (list 'foo))) > > may or may not unify pending interpretation. > > Hope this clarifies things. Let me know if there are other pitfalls > or bugs in the code. > > Cheers > > Marco > > > > > > -- > Marco Antoniotti > > > _______________________________________________ > cl-unification-devel site list > cl-unification-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-unification-devel

2 1

[cl-unification-devel] a simpler example
by Russell McManus 10 Jun '08

10 Jun '08

Here are some examples: ;; this works (find-variable-value '?s (unify #T(list ?f ?s) '(a (b c)))) ;; this works (find-variable-value '?s1 (unify #T(list ?f (?s1 ?s2)) '(a (b c)))) ;; this fails (find-variable-value '?s1 (unify #T(list ?f (list ?s1 ?s2)) '(a (b c)))) I was expecting the meaning of LIST to be the same whether it is encountered at top level in a template, or at a nested level. Is this a bug, or are my expectations wrong? -russ

2 1

[cl-unification-devel] simple question
by Russell McManus 05 Jun '08

05 Jun '08

I'm just learning how to use cl-unification. I have written some code that doesn't work the way I expect, but of course this probably means that my expectations are wrong. Can one of the cl-unification gurus take a look, and let me know what I'm doing wrong? Thanks, -russ (defpackage :unification-demo (:use :cl :CL.EXT.DACF.UNIFICATION)) (in-package :unification-demo) (declaim (optimize (debug 3) (speed 0))) (defclass call-expr () ((rator :reader rator) (rands :reader rands))) (defmethod initialize-instance :after ((call-expr call-expr) &key form) (with-slots (rator rands) call-expr (destructuring-bind (rator-form &rest rand-forms) form (setf rator rator-form rands (mapcar (lambda (rand-form) (parse-expr rand-form)) rand-forms))))) (defclass var-ref () ((var :initarg :var :reader var))) (defclass let-binding () ((var :reader let-binding-var :initarg :var) (expr :reader let-binding-expr :initarg :expr))) (defmethod initialize-instance :after ((let-binding let-binding) &key form) (with-slots (var expr) let-binding (destructuring-bind (var-form expr-form) form (setf var var-form expr (parse-expr expr-form))))) (defclass let-expr () ((bindings :reader bindings) (body :reader body))) (defmethod initialize-instance :after ((let-expr let-expr) &key form) (with-slots (bindings body) let-expr (destructuring-bind (binding-forms body-form) (cdr form) (setf bindings (mapcar (lambda (form) (make-instance 'let-binding :form form)) binding-forms) body (parse-expr body-form))))) (defun parse-expr (form) (flet ((car-match (indicator) (and (consp form) (eql (car form) indicator))) (constant-match () (or (stringp form) (numberp form)))) (cond ((constant-match) form) ((car-match 'let) (make-instance 'let-expr :form form)) ((car-match 'lambda) (make-instance 'lambda-expr :form form)) ((consp form) (make-instance 'call-expr :form form)) ((symbolp form) (make-instance 'var-ref :var form)) (t (error "unhandled form ~A" form))))) ;; this works (find-variable-value '?bs (unify #T(let-expr bindings ?bs) (parse-expr '(let ((x 1) (y 2)) (+ x y))))) ;; this fails, why? (find-variable-value '?b (unify #T(let-expr bindings (list ?b &rest ?bs)) (parse-expr '(let ((x 1) (y 2)) (+ x y)))))

1 0

[cl-unification-devel] Patch to remove warning
by Norman Werner 14 Jan '08

14 Jan '08

Hello, When trying to unify something with a character eg: (cl.ext.dacf.unification:unify '(let ?bindings . ?forms) '(LET ((LAST-POINT-POS (POSITION #\. FILENAME :FROM-END T))) (SUBSEQ FILENAME (+ LAST-POINT-POS 1)))) currently a warning is signaled: -> WARNING: Occurrence test unimplemented for pattern #\. of type STANDARD-CHAR; returning false. If you think this could be of general interest you may include the following method in unifier.lisp: (defmethod occurs-in-p ((var symbol) (pat character) env) ; This is useless, but it's here for completeness. (declare (ignore env)) nil) Regards Norman -- Norman Werner Im Sommerwind 1a 70563 Stuttgart

2 1

[cl-unification-devel] New version with a few little mistakes fixed.
by Marco Antoniotti 09 Nov '07

09 Nov '07

Hi there is a new version of CL-UNIFICATION with a few mistakes fixed (especially Ivan's long standing else-clause problem with MATCH-CASE) ready in CVS. Also, I added two new system build files which reflect the name of the project ('cl-unification'). Eventually 'unification.system' and 'unification.asd' will be removed from CVS, and thus from the project. Please let me know if there are any glitches. One change to MATCH in particular may break some code, although none of mine. Cheers -- Marco Antoniotti

1 0

[cl-unification-devel] Re: Two UNIFICATION patches
by Marco Antoniotti 20 Aug '07

20 Aug '07

Thanks Ivan I will apply the patches as soon as I get a regular Internet connection. Meanwhile I will forward the message to the mailing list so that other people may patch accordingly. Cheers Marco On Aug 17, 2007, at 6:03 AM, Ivan Boldyrev wrote: > Dear Marco! > > I tried your UNIFICATION package and liked it very much. However, > you didn't fix MATCH-CASE completely: when :errorp t, incorrect code > is generated because (rest otherwise-clause) is used even if > otherwise-clause is (error ...). See the patch: > > --- cl-unification/match-block.lisp~ 2007-05-21 19:33:07.000000000 > +0700 > +++ cl-unification/match-block.lisp 2007-08-17 16:58:14.000000000 > +0700 > @@ -181,14 +181,14 @@ > clauses)) > (otherwise-clause > (if otherwise-clause-present-p > - (first (last clauses)) > + (rest (first (last clauses))) > (when errorp > - `(error 'unification-non-exhaustive > - :format-control "Non exhaustive > matching.")))) > + `((error 'unification-non-exhaustive > + :format-control "Non exhaustive > matching."))))) > ) > (labels ((generate-matchers (clauses) > (if (null clauses) > - `(progn ,@(rest otherwise-clause)) > + `(progn ,@otherwise-clause) > (destructuring-bind (pattern &rest body) > (car clauses) > `(handler-case (match (,pattern ,object-var) > > -- > Ivan Boldyrev > > Today is the FIRST day of the REST of your > life. -- Marco Antoniotti, Associate Professor DISCo, Università Milano Bicocca Via Bicocca degli Arcimboldi 8, U7, 4 piano I-20126 Milan (MI) ITALY Please note that I am not checking my Spam-box anymore.

1 0

Re: [cl-unification-devel] Fixed a few glitches in CL-UNIFICATION
by Marco Antoniotti 28 May '07

28 May '07

Thanks I think there may still be a few glitches with the #T read macro and its interaction with the compiler. I have a MAKE-LOAD-FORM versione mostly ready, but I am still ironing out the details. Cheers Marco On May 25, 2007, at 4:04 PM, Masayuki Onjo wrote: > Hi, Marco. > >> I fixed anumber of glitches in CL-UNIFICATION, especially w.r.t. >> MATCH-CASE and friends. > > It works very well with AllegroCL/LispWorks/SBCL/CLISP. > > Thank you, > Masayuki Onjo -- Marco Antoniotti

1 0

[cl-unification-devel] Fixed a few glitches in CL-UNIFICATION
by Marco Antoniotti 21 May '07

21 May '07

Hi I fixed anumber of glitches in CL-UNIFICATION, especially w.r.t. MATCH-CASE and friends. Please check if things are still ok. Cheers Marco -- Marco Antoniotti

1 0