From pinterface at gmail.com Sat Jan 16 05:43:52 2010 From: pinterface at gmail.com (Pixel // pinterface) Date: Fri, 15 Jan 2010 23:43:52 -0600 Subject: [cl-unification-devel] Questions and patches involving cl-unification's MATCH* macros Message-ID: <0ba101ca966e$e401c290$3100a8c0@trinity> 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, # ;; 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 :error-value ) ) => (m-v-b (#:env #:error) (unify** "foo" "foo") (cond ((and #:error ) (error #:error)) (#:error ) (t (let* (#| template vars |#) )))) so UNIFICATION-FAILUREs inside 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 -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. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: 7-Redefine MATCH-CASE in terms of MATCHING.patch Type: application/octet-stream Size: 3252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6-use one variable in MATCHING.patch Type: application/octet-stream Size: 2339 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 5-Make MATCHING agree with MATCH.patch Type: application/octet-stream Size: 1461 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 4-Use &body.patch Type: application/octet-stream Size: 1506 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 3-Fix (matching (otherwise ...)).patch Type: application/octet-stream Size: 834 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2-Extract wrap forms with bindings.patch Type: application/octet-stream Size: 6090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1-Use (unify-star ...).patch Type: application/octet-stream Size: 854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0-Extract TEMPLATE-FOR-MATCH.patch Type: application/octet-stream Size: 1727 bytes Desc: not available URL: From marcoxa at cs.nyu.edu Mon Jan 18 06:53:09 2010 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Mon, 18 Jan 2010 07:53:09 +0100 Subject: [cl-unification-devel] Questions and patches involving cl-unification's MATCH* macros In-Reply-To: <0ba101ca966e$e401c290$3100a8c0@trinity> References: <0ba101ca966e$e401c290$3100a8c0@trinity> Message-ID: <03138260-7E88-4874-85B5-59929BB785BC@cs.nyu.edu> Hello there. thanks a lot for all the work. I have read through the messages and I agree with your analysis with a few comments. I think all the changes you propose are worth including. Let me comment on a few of these. On Jan 16, 2010, at 06:43 , Pixel // pinterface wrote: > 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.) Yep. Most of the code in the MATCH-BLOCK file is cut'n'paste. > > 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. This is good. However, I would set up a bunch of regression tests before moving on and change things. I usually use the test suite from Franz, but I'd be willing to change to another test suite. > > ** (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)) > ? Most implementations expand IGNORE-ERRORS in something like that. But I agree that (as you point out later on) that UNIFY* should be written as (defmethod unify* (a b &optional (env (make-empty-environment))) (handler-case (unify a b env) (unification-failure () nil)) In this way other conditions are passed on. > > 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. Yep. See above. > 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. Yep. > > > ** (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. Good catch. > ** &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. :) I agree. It is better self documentation as well. > ** 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. I think this is ok as well. > > ** 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, # ;; 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. :) I agree with this as well. The behavior you suggest is the one that's needed. > ** 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? Never attribute to malice what can be attributed to incompetence. Of course it is a side-effect of the implementation :) I knew I needed a test suite :) > > If a side effect of implementation, would it make sense to redefine > MATCH to > have an expansion more like > (match ("foo" "foo" :errorp :error-value ) ) => > (m-v-b (#:env #:error) (unify** "foo" "foo") > (cond > ((and #:error ) (error #:error)) > (#:error ) > (t (let* (#| template vars |#) > )))) > so UNIFICATION-FAILUREs inside 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 -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? Having the :NAMED option would be preferable, with NIL or the macro name as fall-back. > (No patch for this one, either.) > > > ** Apologies > > Sorry about the massive brain dump. I /may/ have gotten carried > away. :) Absolutely not. All of this is most welcome. I am just a little swamped (what an euphemism!) and maybe not all that reactive. But let's keep the discussion going. all the best Marco From marcoxa at cs.nyu.edu Mon Jan 18 06:55:41 2010 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Mon, 18 Jan 2010 07:55:41 +0100 Subject: [cl-unification-devel] Test suite? Message-ID: <4BEB2AAC-2F6B-4232-AD0D-D54FFCB27061@cs.nyu.edu> 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 From marcoxa at cs.nyu.edu Mon Jan 18 06:58:30 2010 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Mon, 18 Jan 2010 07:58:30 +0100 Subject: [cl-unification-devel] Questions and patches involving cl-unification's MATCH* macros In-Reply-To: <0ba101ca966e$e401c290$3100a8c0@trinity> References: <0ba101ca966e$e401c290$3100a8c0@trinity> Message-ID: <19830618-FC92-40E6-B9FB-C0ED80B3C3B2@cs.nyu.edu> On Jan 16, 2010, at 06:43 , Pixel // pinterface wrote: > > 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/ I was actually toying with the idea of moving to git. But I have darcs installed as well. If I remember, darcs is supported by cl.net, isn't it? -- Marco Antoniotti From pinterface at gmail.com Fri Jan 22 01:14:06 2010 From: pinterface at gmail.com (Pixel // pinterface) Date: Thu, 21 Jan 2010 19:14:06 -0600 Subject: [cl-unification-devel] Questions and patches involvingcl-unification's MATCH* macros References: <0ba101ca966e$e401c290$3100a8c0@trinity> <19830618-FC92-40E6-B9FB-C0ED80B3C3B2@cs.nyu.edu> Message-ID: <104f01ca9b00$32b10e10$3100a8c0@trinity> "Marco Antoniotti" said: > On Jan 16, 2010, at 06:43 , Pixel // pinterface wrote: > > 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/ > > I was actually toying with the idea of moving to git. But I have > darcs installed as well. If I remember, darcs is supported by cl.net, > isn't it? git would also be a fine choice. Both are supported by cl.net[1]. [1] http://common-lisp.net/viewrep.shtml -- From pinterface at gmail.com Sat Jan 23 00:26:40 2010 From: pinterface at gmail.com (Pixel // pinterface) Date: Fri, 22 Jan 2010 18:26:40 -0600 Subject: [cl-unification-devel] Questions and patches involvingcl-unification's MATCH* macros References: <0ba101ca966e$e401c290$3100a8c0@trinity> <03138260-7E88-4874-85B5-59929BB785BC@cs.nyu.edu> Message-ID: <111701ca9bc2$bd280e00$3100a8c0@trinity> "Marco Antoniotti" sayeth thusly: > Hello there. > > thanks a lot for all the work. I have read through the messages and I > agree with your analysis with a few comments. > > I think all the changes you propose are worth including. > > Let me comment on a few of these. Woo! Glad to know I didn't get myself lost digging around. :) > On Jan 16, 2010, at 06:43 , Pixel // pinterface wrote: [snip] > > 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. > > This is good. However, I would set up a bunch of regression tests > before moving on and change things. I usually use the test suite from > Franz, but I'd be willing to change to another test suite. Agreed. More tests are needed. I'll add that to my TODO list. :) I have no preference for any particular test suite; largely because I (regrettably) have no experience with any of the myriad of test suites available. I'm good with whatever. [snip] > > ** 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? > > Never attribute to malice what can be attributed to incompetence. Of > course it is a side-effect of the implementation :) I knew I needed a > test suite :) Well, "incompetence" hardly seems fair to yourself! It's a tricky bit, that. > > ** :MATCH-NAMED, :MATCHING-NAMED, :MATCH-CASE-NAMED > > > > It seems a bit redundant to have -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? > > Having the :NAMED option would be preferable, with NIL or the macro > name as fall-back. Should :-NAMED also work, for backwards-compatibility? If yes, should it warn about deprecation during compilation? (A warning that would undoubtedly be lost in the scroll of compilation output, but c'est la vie.) > > ** Apologies > > > > Sorry about the massive brain dump. I /may/ have gotten carried > > away. :) > > Absolutely not. All of this is most welcome. I am just a little > swamped (what an euphemism!) and maybe not all that reactive. But > let's keep the discussion going. Oh, good. I was worried. :) -- From pinterface at gmail.com Sat Jan 23 00:48:15 2010 From: pinterface at gmail.com (Pixel // pinterface) Date: Fri, 22 Jan 2010 18:48:15 -0600 Subject: [cl-unification-devel] Some string-related bugs (and patches) Message-ID: <115701ca9bc5$c088bdd0$3100a8c0@trinity> 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/ ) -------------- next part -------------- A non-text attachment was scrubbed... Name: Fix typo.patch Type: application/octet-stream Size: 898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Handle case-sensitive properly.patch Type: application/octet-stream Size: 1403 bytes Desc: not available URL: From pinterface at gmail.com Wed Jan 27 03:57:28 2010 From: pinterface at gmail.com (Pixel // pinterface) Date: Tue, 26 Jan 2010 21:57:28 -0600 Subject: [cl-unification-devel] Test suite? References: <4BEB2AAC-2F6B-4232-AD0D-D54FFCB27061@cs.nyu.edu> Message-ID: <151701ca9f04$d9b4f0c0$3100a8c0@trinity> "Marco Antoniotti" asked for more tests by saying > 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. Moar tests attached, sah! Mostly testing the assorted MATCH* macros. Most of the new tests fail in an unpatched cl-unification, and some still don't pass in my darcs repo (e.g., because I haven't fixed MATCH[F] yet). Obviously, this makes the attached tests pretty useless from the standpoint of ensuring my previous and future patches don't break stuff that currently works, so more tests are still definitely needed. :) The attached patch also makes unification-tests.lisp #'load-able in both ACL and any lisp supported by the portable version of their util.test thingy (ptester), which makes running the test suite as easy as a C-c C-l in slime. -- pix -------------- next part -------------- A non-text attachment was scrubbed... Name: tests.patch Type: application/octet-stream Size: 3621 bytes Desc: not available URL: