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

[cl-unification-devel] Newbie Question on logic and CL-UNIFICATION
by Brad Beer 17 May '11

17 May '11

I'm looking for a (very) simple tool for doing prolog style logical deduction in common lisp. This is just for managing tasks and creating an advanced todo list based on rules. Currently PaiProlog breaks and I don't have the time to read all of PIA to understand what, ether me or it are doing wrong. As an example of what I'm trying to do: (<- (PRODUCER ?X) (TOOL ?X)) (<- (tool "emacs")) (?- (producer "emacs")) Yes (do-all (?- (producer ?x)) Firstly, should I be using CL-Unification for this? Secondly, does CL-Unification support this already? Finally, a simple example of how to do this would be wonderful.

2 1

[cl-unification-devel] sequence template bug?
by Robert Brown 19 Feb '11

19 Feb '11

I think vectors should unify with sequence templates. This expression (unify #(0 1 42 3 4 5) #T(sequence 0 1 ?x 3 4 5)) currently fails. How does the following patch look? bob ========== *** test/unification-tests.lisp#1 Wed Feb 16 16:51:33 2011 --- test/unification-tests.lisp Thu Feb 17 15:06:27 2011 *************** *** 99,104 **** --- 99,106 ---- (test t (unify:environment-p (unify #C(0 1) #T(complex #C(0 1))))) (test '(42 T) (v? '?x (unify #T(number ?x) 42)) :multiple-values t) + (test '(42 T) (v? '?x (unify #(0 1 42 3 4 5) #T(sequence 0 1 ?x 3 4 5))) + :multiple-values t) (test-error (unify 42 #T(float 42.0)) :condition-type 'unification-failure *** unifier.lisp#1 Wed Feb 16 16:51:33 2011 --- unifier.lisp Thu Feb 17 15:09:24 2011 *************** *** 476,482 **** :format-arguments (list a b))) ! (defmethod unify ((a vector) (b vector-template) &optional (env (make-empty-environment)) &key &allow-other-keys) (let ((template-lambda-list (sequence-template-lambda-list b)) --- 476,482 ---- :format-arguments (list a b))) ! (defmethod unify ((a vector) (b sequence-template) &optional (env (make-empty-environment)) &key &allow-other-keys) (let ((template-lambda-list (sequence-template-lambda-list b))

2 1

[cl-unification-devel] implement ASDF testing
by Robert Brown 14 Feb '11

14 Feb '11

I'd ilke to add the ability to test cl-unification by evaluating either of: (asdf:test-system 'cl-unification) (asdf:test-system 'cl-unification-test) The change involves adding one line: :in-order-to ((test-op (test-op :cl-unification-test))) to cl-unification.asd and adding the cl-unification-test.asd file below. Any objections? bob ========== ;;;; cl-unification-test.asd (in-package #:asdf) ;; Tests implemented using the ptester framework are run at *load* time, so ;; we tell ASDF that loading a file containing ptester code is never done. ;; This causes ASDF to run all the tests whenever ASDF:LOAD-SYSTEM or ;; ASDF:TEST-SYSTEM is called with argument CL-UNIFICATION-TEST. (defclass ptester-source-file (cl-source-file) () (:documentation "A Common Lisp source file containing ptester code.")) (defmethod operation-done-p ((operation load-op) (component ptester-source-file)) nil) (in-package #:common-lisp-user) (defpackage #:cl-unification-test-system (:use #:common-lisp #:asdf)) (in-package #:cl-unification-test-system) (defsystem #:cl-unification-test :depends-on (:cl-unification :ptester) :components ((:module "test" :components ((:ptester-source-file "unification-tests")))))

2 1

[cl-unification-devel] MATCH* Patch Updates
by Pixel // pinterface 06 Feb '10

06 Feb '10

Greetings all! Well, Marco, at any rate. =) I've pushed a few more patches to my darcs repo[1]. The most notable changes: 1. MATCH, MATCHF, MATCHING, MATCH-CASE, and MATCHF-CASE are all expanded by a single, unified function. Because it was trivial, I also added MATCH-COND, MATCHF-COND, MATCH-ECASE, and MATCHF-ECASE. 2. Documentation is, rather than being duplicated by hand, set per macro group. So MATCH and MATCHF share a single docstring; as do MATCH-COND, MATCHF-COND, and MATCHING; as do the -CASE macros. It seemed preferable to the possibility of copy-paste errors. 3. An (enable-template-reader) macro now exists, to selectively enable the template reader macro. This is handy in case of conflicts with other reader macros on #T (e.g., closure-html's). 4. If named-readtables is also loaded, creates a named readtable unify:template-reader. (in-readtable ...) is a beautiful thing. In spite of the extra control-flow macros, 1 and 2 ended up making match-block.lisp shorter than the version in CVS. Of course, that comes at the cost of the internal %match-expander function being hairy enough to warrant a 45-line docstring explaining the interaction between its arguments. ... I'll see about simplifying that. :) Still needs more tests, but it should be getting closer. [1] http://repo.kepibu.org/cl-unification/

1 0

[cl-unification-devel] Test suite?
by Marco Antoniotti 27 Jan '10

27 Jan '10

Dear all, the last message by Pixel calls - ultimately - for a test suite for CL- UNIFICATION. I usually use the simple test suite from Franz. Anybody has a different suggestion? Also, I would like to see CL-UNIFICATION tests come in in order to make a good regression test for the library. all the best -- Marco Antoniotti

2 1

[cl-unification-devel] Some string-related bugs (and patches)
by Pixel // pinterface 23 Jan '10

23 Jan '10

I was strolling through what little cl-unification currently has for a test suite, and discovered a couple of issues: 1. "Cannot" is incorrectly spelled "Connot". Darn typos. :) see "Fix typo.patch" 2. (unify string-a string-b env :case-sensitive t) is handled improperly see "Handle case-sensitive properly.patch" If char= or string= returned nil due to a case mismatch, it would fall through to the case-insensitive matching, and erroneously match. Whoops! 3. Code and documentation disagree: is it *unify-string-case-sensitive-p* or *unify-string-case-INsensitive-p* ? The code is sensitive, the documentation is insensitive. But which to deign correct? ( The attached patches, and a few others related to my work in the ) ( previous e-mail, are also in my darcs repo, ) ( http://repo.kepibu.org/cl-unification/ )

1 0

[cl-unification-devel] Questions and patches involving cl-unification's MATCH* macros
by Pixel // pinterface 23 Jan '10

23 Jan '10

Greetings! I was looking into improving the efficiency of MATCH-CASE and while working on that I've ended up with a few questions regarding some implementation decisions, and drafted up some patches both to help you see my thoughts and for consideration of inclusion if you think they're in the right direction. Patches are numbered in the order created, and generally depend on lower-numbered patches (not always intentionally--it's hard to avoid inter-patch dependencies when making multiple changes to a small area). I thought I made the patches in a reasonable order while I was making them, but I find myself referring to them in a different sequence than what I made them in, so apologies if that causes any confusion. I've also put up a darcs mirror (in darcs2 format) of the CVS repository plus the attached patches, in case you find that more convenient. You can find it at http://repo.kepibu.org/cl-unification/ ** Duplicate code There's a fair bit of code duplication between MATCH, MATCHF, and MATCHING in the form of GENERATE-VAR-BINDINGS and the production of the let forms that surround FORMS in those macros. (Nevermind that MATCH and MATCHF are identical except in what they do with template.) Patches 0 and 2 help somewhat. 0) Extract template handling of MATCH[ING] into %TEMPLATE-FOR-MATCH Should be fairly self-explanatory; not much of a win in lines. 2) Extract the bits that wrap forms with bindings for template variables This patch extracts the assorted flet GENERATE-VAR-BINDINGS into a single common function. It's slightly less straightforward than that, however, because it also extracts the (let ...) forms which actually used those bindings. This results in a decent win for code size, but in some cases it swaps the order of execution of %TEMPLATE-FOR-MATCH and COLLECT-TEMPLATE-VARS. I'm pretty sure this doesn't have any noticable effect, but thorough testing is probably wise. ** (unify* ...) and (ignore-errors (unify ...)) The MATCHING macro produces the form (ignore-errors (unify ...)), presumably because it existed before the convenience function UNIFY*. But I'm curious about UNIFY* and/or the ignore-errors form in MATCHING. Is ignore-errors the proper form in either of these places, or was it just easier to type than (handler-case (unify ...) (unification-failure () nil)) ? Looking at some of the assorted UNIFY methods, I see UNIFICATION-FAILUREs aren't the only possible condition which might be thrown during unification (e.g., LAMBDA-LIST-PARSING-ERROR is also a possibility). However, while MATCHING treats any error as a failure to unify, MATCH, MATCHF, MATCH-CASE, and MATCHF-CASE all limit themselves to only UNIFICATION-FAILUREs. This inconsistency leads me to wonder which is correct. I assume only UNIFICATION-FAILUREs should be treated as such in patch 5 because all ERRORs seems a bit heavy-handed in a language with such an excellent condition system, but can see the argument that any error /is/ a failure to unify. 1) Use (unify* ...) rather than (ignore-errors (unify ...)) Same thing, so might as well use the convenience function. Not particularly exciting. And this bit is changed again in patch 5 to ignore only UNIFICATION-FAILUREs. 5) Make MATCHING agree with MATCH[F][-CASE] about the conditions of failure Rather than skipping to the next clause on any error, UNIFICATION-FAILUREs--and /only/ UNIFICATION-FAILUREs--skip to the next clause. Under the assumption that UNIFY* is implemented as intended, this creates a new utility function UNIFY** (terrible name, I know!) which is like UNIFY* but ignores /only/ UNIFICATION-FAILUREs rather than all ERRORs. This of course results in a library-user-visible change to how MATCHING operates, which may or may not be considered acceptable. ** (matching (otherwise ...)) 3) Fix (matching (otherwise ...)) (matching (otherwise ...)) expands into (cond (otherwise ...)), which generates an unbound-variable error when executed, because COND does not special-case OTHERWISE as CASE does. Pretty self-explanatory and not very interesting. ** &body vs. &rest 4) Use &body instead of &rest for (arguably) prettier auto-indentation I prefer the smaller indentation provided with using &body instead of &rest. Not a big deal either way, but I was in there so I figured I'd throw it in the mix. Fortunately, if you disagree, this patch shouldn't affect any of the others. :) ** Multiple #:UNIFICATION-ENVs in MATCHING 6) Only use one variable to store the unification environment in MATCHING Because of the way MATCHING expands, and what UNIFY** returns, each (setf #:env (unify** ...)) call will do one of two things: it will set #:env to NIL or it will set #:env to an ENVIRONMENT structure. If #:env is set to NIL--the same value it entered the (setf) with!--the COND will continue on to the next clause. If #:env is set to an ENVIRONMENT structure, none of the remaining (setf) clauses will be evaluated. Thus, because the variable will only ever be set to a non-nil value once, this is perfectly safe. ** MATCH-CASE MATCH-CASE has the surprising behavior of (ignore-errors (match-case ("foo") ("foo" (error 'unification-failure)) (t :default))) => :default Hardly CASE-like behavior! I think it sensible to redefine MATCH-CASE in terms of MATCHING, rather than MATCH. E.g., so the above would expand into something like (ignore-errors (let ((#:object-var "foo")) (matching (:errorp nil :default-substitution nil :matching-named nil) (("foo" #:object-var) (error 'unification-failure)) (t :default)))) which greatly simplifies the definition of MATCH-CASE and makes it much more CASE-like in behavior. 7) Redefine MATCH-CASE in terms of MATCHING This both greatly simplifies the MATCH-CASE macro as well as its expansion. HOWEVER, this version is *NOT* 100% compatible with the previous version. Specifically, UNIFICATION-FAILUREs signalled from within clause-forms will /not/ cause the next unification clause to be attempted, but will instead propogate outward as the -case name suggests they should. That is, (ignore-errors (match-case ("foo") ("foo" (error 'unification-failure ...)) (t :default))) => :default ;; before patch => nil, #<unification-failure> ;; after patch Patch 7 suggests that MATCHING, MATCH-CASE, MATCHF-CASE, and the possible future MATCH-COND and MATCHF-COND are all fairly trivial variations on each other. I'll be happy to explore that possibility in future patches if it's of interest, but I'm already asking you to look at too many patches at once, so I'll refrain for now. :) ** MATCH Though documented, MATCH's behavior when its body forms signal UNIFICATION-FAILURE seems at odds with expectations, for pretty much the same reason the behavior seems nonsensical in MATCH-CASE. Was it a deliberate design decision, or a side-effect of how MATCH was implemented? If a side effect of implementation, would it make sense to redefine MATCH to have an expansion more like (match ("foo" "foo" :errorp <e?> :error-value <ev>) <body>) => (m-v-b (#:env #:error) (unify** "foo" "foo") (cond ((and #:error <e?>) (error #:error)) (#:error <ev>) (t (let* (#| template vars |#) <body>)))) so UNIFICATION-FAILUREs inside <body> can be independent of errorp? (No patch for this one yet.) ** :MATCH-NAMED, :MATCHING-NAMED, :MATCH-CASE-NAMED It seems a bit redundant to have <macro-name>-named arguments for block names rather than simply having a :named argument as in, say, LOOP. Any particular reason it wasn't done that way? (No patch for this one, either.) ** Apologies Sorry about the massive brain dump. I /may/ have gotten carried away. :)

2 4

[cl-unification-devel] New patches added to CL-UNIFICATION.
by Marco Antoniotti 17 Dec '09

17 Dec '09

Dear all, I added a few patches to CL-UNIFICATION (mostly thanks to Pixel // pinterface w.r.t. CL-PPCRE intergation). I have not added the ASDF-SYSTEM-CONNECTION patch because I still have a few things to double check. Please upgrade and let me know if you find any bug. Cheers -- Marco Antoniotti

1 0

[cl-unification-devel] Updated patch to cl-ppcre integration
by Pixel // pinterface 01 Dec '09

01 Dec '09

This replaces my previous patch to cl-ppcre.lisp. In addition to the previous functionality changes/bug fixes, it converts 'unify to use #'cl-ppcre:scan-to-strings, which simplifies the logic somewhat. It also fixes a bug involving unbound register groups. That is: (match (#T(regexp "(foo)(bar)?baz" (?x ?y)) "foobaz") (values x y)) will now return "foo", nil rather than signaling a type-error.

1 0

[cl-unification-devel] Patches for improving cl-ppcre integration
by Pixel // pinterface 19 Nov '09

19 Nov '09

For your consideration: defsystem.patch changes cl-unification.asd to use asdf-system-connections to ensure the cl-ppcre bits are loaded when both cl-unification and cl-ppcre are loaded, eliminating load-order issues which were otherwise causing me trouble. This eliminates the need for cl-unification-lib.asd entirely. cl-ppcre.patch alters regex unification to: A) signal 'unification-failure when cl-ppcre:scan returns nil (no match), rather than triggering undefined behavior with inaccurate type declarations, or type-errors with (= nil <number>). B) consider any match, rather than only a match of the entire string, to be a successful unification. Presumably, if one desires a match across the entire string, they'll be using the appropriate anchors.

1 0