mantoniotti@common-lisp.net [Tue, 13 Mar 2012 15:29:16]
mantoniotti@common-lisp.net [Tue, 13 Mar 2012 15:28:28]
mantoniotti@common-lisp.net [Tue, 13 Mar 2012 15:28:15]
mantoniotti@common-lisp.net [Thu, 16 Jun 2011 00:10:47]
rbrown@common-lisp.net [Sat, 02 Apr 2011 04:39:32]
Change the documentation.
rbrown@common-lisp.net [Sat, 02 Apr 2011 04:19:09]
code that uses them is correctly indented by editors.
mantoniotti@common-lisp.net [Sat, 02 Apr 2011 04:16:51]
mantoniotti@common-lisp.net [Sat, 02 Apr 2011 04:11:54]
mantoniotti@common-lisp.net [Sat, 02 Apr 2011 04:09:17]
mantoniotti@common-lisp.net [Sat, 02 Apr 2011 04:08:13]
mantoniotti@common-lisp.net [Sat, 02 Apr 2011 04:05:30]
mantoniotti@common-lisp.net [Sat, 02 Apr 2011 04:05:18]
mantoniotti@common-lisp.net [Sat, 02 Apr 2011 04:01:24]
mantoniotti@common-lisp.net [Sat, 02 Apr 2011 03:51:38]
rbrown@common-lisp.net [Sat, 02 Apr 2011 03:50:19]
with ~@<newline> format directives.
rbrown@common-lisp.net [Sat, 02 Apr 2011 02:51:32]
test/unification-tests.lisp: new test to verify the change
rbrown@common-lisp.net [Sat, 02 Apr 2011 02:49:30]
rbrown@common-lisp.net [Sat, 02 Apr 2011 02:47:50]
Make (asdf:test-system 'cl-unification) work.
rbrown@common-lisp.net [Sat, 02 Apr 2011 02:37:58]
before the forms are read. This fixes compilation of
file unification-tests.lisp.
mantoniotti@common-lisp.net [Tue, 29 Mar 2011 23:22:33]
mantoniotti@common-lisp.net [Tue, 29 Mar 2011 23:20:53]
mantoniotti@common-lisp.net [Tue, 29 Mar 2011 22:59:37]
pix@kepibu.org [Tue, 15 Jun 2010 03:21:37]
I'd like to tell you this is part of a plan to simplify %match-expander, but in
all honesty, the only reason I'm doing it is because I found myself thinking
with-unification-variables would be a handy macro while working on a private
extension to cl-unification, and I didn't want to duplicate the code.
pix@kepibu.org [Sun, 07 Feb 2010 08:42:39]
pix@kepibu.org [Sun, 07 Feb 2010 07:40:23]
pix@kepibu.org [Sun, 07 Feb 2010 07:33:38]
pix@kepibu.org [Sun, 07 Feb 2010 07:30:06]
pix@kepibu.org [Fri, 05 Feb 2010 09:30:48]
pix@kepibu.org [Fri, 05 Feb 2010 09:04:00]
Because (in-readtable ...) is a beautiful thing.
pix@kepibu.org [Fri, 05 Feb 2010 09:02:42]
Useful when there are conflicts on #T, such as with closure-html.
pix@kepibu.org [Fri, 05 Feb 2010 08:58:50]
pix@kepibu.org [Fri, 05 Feb 2010 03:21:40]
pix@kepibu.org [Thu, 04 Feb 2010 07:32:18]
And, because it's now trivial, add MATCH-COND, MATCHF-COND, MATCH-ECASE, and
MATCHF-ECASE.
Still to do: Merge documentation of functions so there's less copy-pasta in the
documentation strings.
pix@kepibu.org [Thu, 04 Feb 2010 07:31:47]
pix@kepibu.org [Thu, 04 Feb 2010 07:20:04]
pix@kepibu.org [Wed, 03 Feb 2010 09:56:58]
pix@kepibu.org [Wed, 03 Feb 2010 09:53:59]
pix@kepibu.org [Mon, 25 Jan 2010 07:38:54]
pix@kepibu.org [Mon, 25 Jan 2010 07:38:27]
...why is this not default behavior?
pix@kepibu.org [Mon, 25 Jan 2010 07:03:27]
pix@kepibu.org [Sat, 23 Jan 2010 00:53:33]
pix@kepibu.org [Sat, 23 Jan 2010 00:31:24]
pix@kepibu.org [Sat, 23 Jan 2010 00:19:32]
pix@kepibu.org [Thu, 21 Jan 2010 01:56:47]
Let errors which are not UNIFICATION-FAILUREs find their way out of UNIFY*.
pix@kepibu.org [Wed, 20 Jan 2010 08:28:50]
pix@kepibu.org [Wed, 20 Jan 2010 08:27:09]
If the first clause doesn't match due to mismatched case, it would
roll down to the second clause, causing case-differing strings to
erroneously match. By checking for case again, we can avoid this.
Note, however, that this does not fix the similar but unrelated
inconsistent usage of *unify-string-case-sensitive-p* and
*unify-string-case-insensitive-p* (the former being used in the code
and the latter appearing in documentation). That bug will remain
until the canonical form is decided upon.
pix@kepibu.org [Wed, 20 Jan 2010 08:09:59]
pix@kepibu.org [Fri, 15 Jan 2010 08:55:05]
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
pix@kepibu.org [Fri, 15 Jan 2010 08:49:26]
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
should be perfectly safe.
pix@kepibu.org [Fri, 15 Jan 2010 07:59:02]
Rather than skipping to the next clause on any error, UNIFICATION-FAILUREs--and
/only/ UNIFICATION-FAILUREs--skip to the next clause.
Next ->