Lambda the Ultimate

What good predicate/pattern matching extensions exist for Lisp? Also, are there any good libraries for static type/assertion checking?

I quite like the syntax we used in Distel, which was Martin Björklund's idea. Whereas in Erlang you write:

    case Result of
        {ok, Value}     -> Value;
        {error, Reason} -> exit(Reason)
    end

in Distel you write:

    (mcase result
      (['ok value]     value)
      (['error reason] (erl-exit reason)))

In summary:

• 'foo matches the symbol foo
• foo binds to the variable foo (multiple occurences must match onto the same value)
• ,foo matches the bound value of the variable foo
• Conses and arrays are matched recursively
• Literals are matched by value

I wrote the pattern-matcher as a simple interpreter. This is an example of fun code that you're allowed to write in Emacs Lisp but would get rotten fruit thrown at you in Common Lisp :-)

Code generated by CLAW does run on Movitz but when I showed off my "Erlang OS" to my Erlang friends they threw rotten fruit at me and told me not to bother them until it runs e.g. Yaws :-)

1. ftp://publications.ai.mit.edu/ai-publications/2001/AITR-2001-006.pdf
"Predicate Dispatching in the Common Lisp Object
System
by
Aaron Mark Ucko

Submitted to the Department of Electrical Engineering and Computer Science on May 11, 2001, in partial fulfillment of the requirements for the degree of Master of Engineering in Computer Science and
Engineering

Abstract
I have added support for predicate dispatching, a powerful generalization of other dispatching mechanisms, to the Common Lisp Object System (CLOS). To demonstrate its utility, I used predicate dispatching
to enhance Weyl, a computer algebra system which doubles as a CLOS library. My result is Dispatching-Enhanced Weyl (DEW), a computer algebra system that I have demonstrated to be well suited for both users and programmers."

The code is in Appendix A (and also available for download at the given URL). I haven't had time to play with it yet, since I haven't needed to. It's probably good enough for most uses, given that the paper also demonstrates a non trivial use.

2. As for pattern matching, I think cl-unification can do the job:
http://common-lisp.net/project/cl-unification/
"The library presented in these pages provides a full blown unification framework for Common Lisp.

Writing a pattern matcher or a an unifier in Common Lisp is easy, as long as we limit ourselves to manipulate only ATOMs and CONSes.

Alas, it would be much nicer if we could manipulate arbitrary Common Lisp objects as the ML programmer can with arbitrary ML objects.

The library presented here is the first one (to the best of the author's knowledge) that is capable of manipulating arbitrary Common Lisp objects.

The hope is that this library could be incorporated directly in an implementation in order to provide better type checking."

It is accompanied by a couple control flow macros:
(http://common-lisp.net/project/cl-unification/control-flow.html)
"In order to make the use of the UNIFICATION library easier, a few utility macros are provided. The macros MATCH, MATCHING, and MATCH-CASE can be used to unify two (or more) objects and then to build a lexical environment where the variables present in the to objects (or templates) are bound to the values resulting from the application of UNIFY.

* MATCH is a "single shot" macro. It does one unification and executes forms in an appropriate lexical environment.
* MATCH-CASE is equivalent to CASE. It tries to match a single object (or template) against a set of clauses. The forms associated to the first clause for which there is a successful unification, are then executed within an appropriate lexical environment.
* MATCHING is equivalent to COND. Each clause contains a head"

Regarding static typing, keep in mind that CL errs on the expressive side of the typing spectrum: it allows expressions which can't be shown to be well-typed at compile time. A static typing library would therefor have to implement only a subset of CL (TypeL http://www.cliki.net/TypeL is trying to do something like that). Nevertheless, SBCL and CMUCL can often infer the type of expressions and issue warnings if type assertions are wrong/not respected.

Allowing currying means we lose n-ary functions. That tradeoff isn't mentioned here. I'd rather have the choice to have n-ary functions. Optional and keyword arguments are extremely useful, and I'm not sure that much is gained by not even giving users the choice to have them.

Well, since Qi is supposed to be better than Haskell, and Haskell can have optional and keyword arguments, I'd bet it wouldn't be too hard to implement.

I stand corrected :)