Beautiful stuff. Brian, thanks for writing that up - I don't think I have used Screamer in 20 years, but I will put playing with it on my TODO list.
I have been using Common Lisp for about 38 years for research and building commercial products, and it is amazing how portable code is through the decades.
Oh wow, Screamer. I used it to write a Sudoku solver 14 years ago, and blogged about it.
http://i-need-closures.blogspot.com/2006/03/
Looking at the code now, well, it's like looking at any code you wrote a decade and a half ago.
Common Lisp was educational but now I just use Python and Javascript to get things done, like everyone else does. I suppose I use the lessons learned from then, though.
Very nice. I too initially had a problem handling a lot of variables, so I used a macro at first to do the typing for me, but with some help from the maintainer I used cl:apply rather than screamer:apply-nondeterministic which worked.
But for real work you should use a proper OR system and solver.
google ortools or COIN-OR for the C/C++ folks and horrible syntax, or any Prolog with solver backend or Picat are much better. Screamer with a proper solver backend would be really nice. Prolog solved it this way.
It is delightful :) Any program written in pure ANSI CL should run without any changes today. Even pre-ANSI code shouldn't be too hard to adapt. In practice, a few people graciously maintain such libraries and make distribution easier and documentation readily available.
common lisp the language hasn't changed since it was standardized, so code written to the strengths of the standard has not experienced bit rot. screamer, series, cmu's ai code archive, old common lisp-based books (like norwig's paradigms of ai) will all work out of the box. that is not to say that the language runtimes are not improving, instead they focus on improvements that complement the standard, but you can grab any old algorithm, and it'll work in recent sbcl.
there are underspecified parts of the standard, notably the protocol around the object oriented system (common lisp object system meta-object protocol), and then there are parts that are not specified at all: networking, interactions with C libraries, unicode, threading. each runtime implements it in its own particular way. that means that the core of something like CLX, which is the network interface to X11, could've stayed exactly the same, but the networking outer layer had to be updated with the details of specific runtimes. in case of X11 that support goes all the way back to lisp machine Genera. on the other hand something like SSL support which will both rely on external C library and concern itself with network, will usually bit rot very rapidly.
there's definitely sub-groups in the computer world who argue for stability. i've first encountered that in common lisp, but i think a recent interest in Ada is also driven by similar concerns. don knuth with TeX and literate programming also comes to mind. for example i wrote my billing code almost 15 years ago, and it's common lisp code that spits out plain TeX file. i've added features to it, but if i were to attempt to run the first version, it'll work without any changes. honestly i personally think it's aesthetically pleasing to work with old code, with changelog spanning a decade, because of the richness of thought that went into it. like picking up a woodworking tool at a yard sale, and noticing all the different hints of care that went into it.
arguing for stability in the face of other tradeoffs is an unpopular position. there are people who do it, but simply linking them from here will probably result in downvotes. i think arguments against systemd or in support of X11 come from people that want to escape the constant marginal benefit refactoring cycle.
I have been using Common Lisp for about 38 years for research and building commercial products, and it is amazing how portable code is through the decades.