A Lisper's first impression of Julia

I have recently looked at Julia, a new programming language developed at MIT that promises to be a dynamic programming language that is suitable for scientific computing with a high-performance implementation. It is an interesting project that heavily borrows from Common Lisp, Dylan, and Scheme, and you can rightfully argue that Julia itself is actually a Lisp dialect. While I wasn’t very impressed with some other recent Lisp dialects (Arc, Clojure), Julia puts a couple of very interesting features on the table. Below is a discussion of the more salient aspects of Julia, as seen from a Common Lispers perspective. It is based on the documentation of the prerelease version 0.3 of Julia.

Julia is closest to Dylan in many regards. It uses a somewhat mainstream syntax rather than s-expressions. Unlike Dylan, you can nevertheless write ‘full’ macros, since macro definitions are implemented in Julia, not some template language, and backquote/quasiquote is integrated with the Julia syntax. Julia is a Lisp-1 (like Scheme or Dylan) rather than a Lisp-2 (like Common Lisp or ISLISP), which makes it necessary to add macro hygiene features. Fortunately, this does not mean you have to deal with the rather painful syntax-case construct of some Scheme dialects, but you can still use far simpler backquote/quasiquote constructions, just with macro hygiene taken care of by default. Julia also allows you to selectively break hygiene. Although I usually strongly prefer the simplicity of Common Lisp’s non-hygienic macro system, the fact that Julia is a Lisp-1 turns macro hygiene into a real problem, so I guess this is a reasonable design.

Julia provides object-oriented programming from the ground up, similar to Dylan. It centers on generic functions rather than classes, where methods are defined outside classes and allow for multiple dispatch, just like in Dylan and Common Lisp. Like Dylan, and unlike Common Lisp, it does not distinguish between functions and generic functions: All functions can have methods, you do not have to make up your mind whether you want methods or plain functions. Unlike in Common Lisp, there are no method combinations, no before/after/around methods, and call-next-method is not directly supported, but has to be done manually. This is probably to simplify method dispatch, maybe to have some performance advantages, though I find it hard to imagine that adding method combinations would make things substantially worse.

You still need a class hierarchy to drive method dispatch. Unlike in Common Lisp, there is no multiple inheritance, only single inheritance. In fact, there is actually no real inheritance, because in Julia, only leaf classes of the class hierarchy are allowed to define slots/fields. All superclasses are required to be “abstract,” without any slot definitions. Also, Julia classes cannot be redefined at runtime, so in fact Julia classes are much closer to Common Lisp’s structured types rather than classes.

Julia’s execution model is based on dynamic compilation. As a user, you don’t have to compile your code at all, source code is just compiled on the fly (similar as in Clozure Common Lisp). Julia inlines functions on the fly, including generic functions, and can de-optimize when function definitions change at runtime. This is more flexible than in Common Lisp, where inlined functions can get out of sync with their potentially changed definitions. Also, while the Common Lisp specification does not say anything with regard to being able to inline generic functions or not, there are aspects in the CLOS MOP specification that prevent generic functions from being inlined, at least for user-defined extensions of generic functions. Julia definitely seems more “modern” here.

In Julia, there is no distinction between variable binding and variable assignment. If you assign to a variable that has not been used before in the same lexical environment, it is silently introduced. In Common Lisp/Scheme/Dylan, there is a distinction between ‘let forms that introduce variable bindings, and assignments (setq/setf/set!) that perform assignments. I’m highly skeptical of Julia’s design here, because this potentially leads to bugs that are hard to find: A simple typo in your source code just may go unnoticed.

In Julia, all variables are lexically scoped (except for some seemingly quirky scoping semantics for global variables, see below). There are no special / dynamically scoped variables in Julia, which is a major omission in my book. Some academics don’t like special scoping, but their presence in Common Lisp is incredibly useful in practice, especially but not only for multi-threading!

Julia’s default representation for integers is either 32-bit or 64-bit integers, depending on the target architecture, which silently wrap around. Julia also supports “BigInts” that can be arbitrarily large, but you have to ask for them explicitly. In Common Lisp, integers are by default arbitrarily large, which I think is an advantage. Due to type tagging in Common Lisp implementations, even “big” integers are typically allocated as immediate values rather than on the heap when they fall into the “fixnum” range. I didn’t find anything in the Julia documentation that discusses this aspect of “BigInt.”

In Julia, all mathematical operations are generic functions and can be extended by user-defined methods. This is a strong advantage for Julia. In Common Lisp, mathematical operations are “plain” functions which cannot be extended. Due to some aspects in the design of Common Lisp’s generic functions, it’s hard to inline (or open-code) them, which is why for performance reasons, it’s better to express mathematical (and other such performance-critical functions) as “plain” functions. Apart from that, the support for number types seems to be on par between Julia and Common Lisp (complex types, rational numbers, floating point numbers, etc.)

In Julia, strings are unicode strings by default. My knowledge about unicode support in Common Lisp implementations is limited, so I cannot really make any comparisons here. One interesting aspect in Julia’s string support is that there can be user-defined macros to parse them and construct other syntactic entities out of them. This feels somewhat similar to read macros in Common Lisp, although with a slightly different scope.

Julia’s support for functions is similar to Common Lisp: They can be first class and anonymous (lambda expressions). There are varargs (&rest), optional and keyword arguments. In Common Lisp, optional and keyword arguments cannot be dispatched on in methods. In Julia, optional arguments can be dispatched on, but not keywords. (This is a pity, dispatch on keyword arguments would be very interesting, and is something I wanted to add as part of Closer to MOP for a long time!)

Julia’s support for control flow is much more limited than in Common Lisp. There are equivalents for progn, cond/if, for and while loops. Unlike Common Lisp, there is no support for a full loop facility, or even for a simple goto construct. Common Lisp clearly wins here. Julia’s support for exception handling is also limited: No handler-bind, no restarts, unlike in Common Lisp, which are also really useful features.

Julia’s type system has some interesting differences to Common Lisp: There is a distinction between mutable and immutable classes. Immutable classes disallow any side effects on their fields. This seems to be primarily directed at enabling stack allocation as an optimization. In Common Lisp, you would use dynamic extent declarations when allocating structs (or other data types) to achieve similar performance improvements. I’m not sure why it would matter that the fields need to be read-only for such an optimization, but if this covers most cases, maybe this is good enough.

Julia allows for returning and receiving multiple values from function calls, similar to Common Lisp. This is a feature I like a lot in Common Lisp, so I’m happy it’s also in Julia. In Julia, this is achieved by an explicit tuple type representation which doesn’t exist in this form in Common Lisp. In Lisp, you could also return/receive lists instead of multiple values, which would correspond to this kind of tuple type, but lists add an additional performance overhead, which multiple values and, presumably, tuples in Julia don’t have.

Julia supports parametric types. I don’t see at the moment why this is relevant. You could achieve similar functionality also with some macrology. Maybe I’m missing something here.

There is a whole section on constructors (make-instance / make-struct) in the Julia manual. This makes me suspicious, this should be an easier topic.

Julia has a module system. It supports export and automatic import of explicitly exported identifiers. You can also still access non-exported identifiers with additional syntax. This is good, because module designers may not always perfectly anticipate what users actually need to access. Common Lisp’s package system supports a similar distinction between external and internal definitions that can be accessed in different ways. I slightly prefer Common Lisp’s ability to use the package name as a prefix even for explicitly exported definitions. There is no feature in Julia to rename imported identifiers, which is something where Common Lisp’s support for explicit package name prefixes can come in very handy. I would like to see something like Oberon’s support for renaming identifiers on import in some Lisp dialect someday, because I believe that is the most complete solution for dealing with potential name conflicts.

In terms of meta-programming, apart from macros, Julia also supports (top-level) eval, like Common Lisp. Julia’s support for “reflection” is much weaker than Common Lisp’s CLOS MOP: You can only inspect types at runtime, but you cannot modify them (and language designers should stop calling something “reflection” that is clearly just “introspection”).

Both Julia and Common Lisp support multi-dimensional arrays. Common Lisp’s arrays are in row-major order, starting at index 0 in every dimension. Julia’s arrays are column-major order, starting at index 1 in every dimension. Julia’s support for multi-dimensional arrays is a library feature, whereas Common Lisp’s support is built into the language. Julia supports both dense and sparse matrices, where Common Lisp supports only dense matrices out of the box.

There are a lot of libraries that ship with Julia targeted at scientific computing.

Julia supports parallel programming with a model built on top of message passing: If you want to run parallel algorithms, you essentially start several instances of Julia that communicate with each other. The model does not support shared memory, and there is no multi-threading within a Julia instance (although there seem to be discussions among the Julia designers to add this in the future). The model is built on top of MPI as an implementation backend. However, the actual programming model supports single-sided communication: You can ask a function to be executed in some other Julia worker process, and can later synchronize with it to fetch results. On top of that, there are some high-level constructs provided as library features, such parallel maps and loops. Julia’s message passing model ensures that within a Julia instance, only one task is executed at a time, so there is yet no need to provide low-level synchronization mechanisms, such as locks or atomic operations. The lack of shared-memory parallelism is problematic because many parallel algorithms that are very easy to express with shared memory become quite complicated in a distributed memory setting. On the other hand, Julia’s model easily supports true distributed programming: You can configure Julia to run several instances across a cluster, and use them in a quite straightforward way: substantially easier than what you have to do with, say, MPI, and much closer with regard to ease of use to modern PGAS languages like Chapel or X10.

The ANSI specification for Common Lisp does not mention anything about multi-threading or parallel programming at all, but many Common Lisp implementations add support for shared-memory parallelism. I will not go into details here, but let me just briefly state that, for example, the LispWorks implementation of Common Lisp provides excellent support for symmetric multiprocessing that is at least on par with what you can find in most other language implementations in terms of parallel programming support. However, unfortunately, support for true distributed memory models seems almost non-existent in Common Lisp, apart for some basic support for MPI in a library that was maintained only for a very short period of time a couple of years ago. Julia looks like a good source of inspiration for adding such features to Common Lisp.

However, one aspect of Julia’s message passing approach seems problematic, as far as I can tell: You can pass closures between different instances of Julia, but it’s not clear how free variables in a lambda expression are bound. It seems that lexical variables are bound and serialized to another process, but global variables are not serialized and need to be present in any presence that may execute the closure. Experiments with adding side effects to free variables in lambda expressions that are passed to other processes seem to suggest that the semantics of this combination of features are unpredictable. At least, I have not been able to figure out what happens when — sometimes variables seem to be updated at the sender’s side, sometimes not — and I didn’t find a discussion of this topic in the Julia manual.

Anyway, as you can tell, there are a lot of interesting features in Julia, and it’s definitely worth a try.

Parenthesis can be tricky...

You probably didn't see this coming.

The Human Consequences of Dynamic Typing

I agree with Jay McCarthy that static typing is anti-human. I think I can give a slightly more elaborate example of a program that every static type checker must reject, but that is nevertheless correct. Everything below is valid Common Lisp:

(defclass person ()
  ((name :initarg :name
         :accessor person-name)))

(defmethod display ((p person))
  (format t "Person: Name ~S, address ~S."
            (person-name p)
            (person-address p)))

A static type checker must reject this program because there is no address field defined in the class person that person-address presumably refers to. However, below is a run of the program in a Lisp listener that runs to a correct completion without fatal (!) errors:

CL-USER 1 > (defvar *p* (make-instance 'person :name "Pascal"))
*P*

CL-USER 2 > (display *p*)

Error: Undefined function PERSON-ADDRESS called with arguments
(#<PERSON 4020059AB3>).
  1 (continue) Try invoking PERSON-ADDRESS again.
  2 Return some values from the call to PERSON-ADDRESS.
  3 Try invoking something other than PERSON-ADDRESS with the
    same arguments.
  4 Set the symbol-function of PERSON-ADDRESS to another
    function.
  5 (abort) Return to level 0.
  6 Return to top loop level 0.

Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for
other options.

CL-USER 3 : 1 > (defclass person ()
                  ((name    :initarg :name
                            :accessor person-name)
                   (address :initarg :address
                            :accessor person-address)))
#<STANDARD-CLASS PERSON 4130371F6B>

CL-USER 4 : 1 > :c 1

Error: The slot ADDRESS is unbound in the object
#<PERSON 41303DD973> (an instance of class
#<STANDARD-CLASS PERSON 4130371F6B>).
  1 (continue) Try reading slot ADDRESS again.
  2 Specify a value to use this time for slot ADDRESS.
  3 Specify a value to set slot ADDRESS to.
  4 (abort) Return to level 0.
  5 Return to top loop level 0.

Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for
other options.

CL-USER 5 : 1 > :c 3

Enter a form to be evaluated: "Belgium"
Person: Name "Pascal", address "Belgium".
NIL

CL-USER 6 > (display *p*)
Person: Name "Pascal", address "Belgium".
NIL

The "trick" is that the Lisp listener allows for interactive modification of a program while it is running. No static type checker can anticipate what modifications will be performed at runtime.

This is not a toy feature of Common Lisp, but something that many Lisp developers rely on. For example, my own ContextL library crucially relies on the very class redefinition feature I demonstrate above. Joe Marshall provides another account how such features can solve real-world problems.

Closer to MOP supports ABCL 1.1.1

The darcs repositories of Closer to MOP now also support ABCL 1.1.1. I plan to make a more official release soon. The Common Lisp implementations currently covered are now as follows: Allegro 9.0, ABCL 1.1.1, CLisp 2.49, Clozure Common Lisp 1.8, CMU CL 20d, ECL 12.12.1, LispWorks 6.0.x and 6.1.x, SBCL 1.1.4, and SCL 1.3.9.

Closer to MOP on ABCL and ECL

Just to report on work in progress: I am currently working in my spare time on making sure that Closer to MOP works (again) with ABCL and ECL. ABCL is in relatively good shape, but still needs a couple of bugs fixed here and there. Rudi Schlatte is doing a fantastic job at responding to bug reports. I'm pretty sure the next release will have excellent Closer to MOP support. ECL's recent version came with several changes in its CLOS MOP implementation which broke a lot of things in Closer to MOP, so the current version of Closer to MOP doesn't work with ECL. I'm doing what I can to make sure Closer to MOP is back to speed again with ECL. However, I can only do this in my spare time, and will be busy moving in the next couple of weeks, so some delays are to be expected...

Arguments against call/cc

An excellent collection of good arguments against having call/cc in a programming language (such as Scheme), by the ever-inspiring Oleg Kiselyow: An argument against call/cc.

Common Lisp, the Untold Story

Nice article by Kent Pitman, mostly about his experiences with the Common Lisp standardization process: Common Lisp, the Untold Story.

100% programmed in Common Lisp, the artificial intelligence applications development language

A short article about an apparently successful digital livescan fingerprinting system.

Bertrand Meyer about John McCarthy...

Nice essay about John McCarthy.

Beware the Purists...

See Beware the Purists, Lest They Kill Your Innovation. Much of what is stated there also strongly applies to programming and programming languages...

The Perils of Partially Powered Languages

Here is a worthwhile read: The Perils of Partially Powered Languages. It's from a Haskell perspective, but should apply to other non-underpowered languages as well. ;)

Complexity metrics other than code size don't mean that much...

See here. To cite:

"El Emam and his colleagues repeated some of those experiments using bivariate analysis so that they could allocate a share of the blame to code size (measured by number of lines) and the metric in question. It turned out that code size accounted for all of the significant variation: in other words, the object-oriented metrics they looked at didn’t have any actual predictive power once they normalized for the number of lines of code. Herraiz and Hassan’s chapter in Making Software, which reports on an even larger study using open source software, reached the same conclusion:

'…for non-header files written in C language, all the complexity metrics are highly correlated with lines of code, and therefore the more complex metrics provide no further information that could not be measured simply with lines of code… In our opinion, there is a clear lesson from this study: syntactic complexity metrics cannot capture the whole picture of software complexity. Complexity metrics that are exclusively based on the structure of the program or the properties of the text…do not provide information on the amount of effort that is needed to comprehend a piece of code—or, at least, no more information than lines of code do.'"

Special variables in Java

Wow. This is how complicated it gets to have he functionality of special variables in a language that really doesn't want them (and it's brought to you by Google): Google Guice

A non-hierarchical approach to object-oriented programming

The Lisp historical archive web site just got reorganized. I have made a quick check of the contents, and found out that Howard I. Cannon's original technical report about Flavors - A non-hierarchical approach to object-oriented programming was finally made available as part of that archive. The report was originally written in 1979, was circulated around Lispers, but was never ever published as an actual technical report, although it is cited as such in several later papers by other authors. It describes the original object-oriented extension to the MIT Lisp Machine, heavily influenced by Smalltalk, but with multiple inheritance and method combinations added (but no multiple dispatch yet, which got only introduced in CommonLoops, a direct predecessor of CLOS). Although unpublished and clearly in an unfinished state, this report itself influenced a lot of other subsequent experiments with object-oriented extensions to Lisp dialects. Among other things, it already mentions the idea of exploring "meta-protocols" for making parts of the implementation of the object-oriented extension itself customizable, which was later investigated in much more detail as part of the work on the CLOS MOP (see also The Art of the Metaobject Protocol). And, of course, method combinations were already a very early predecessor of aspect-oriented programming.

It's good that this very important historical document is finally available!

Now is the time...

Now is the time to switch programming languages: Oracle is the borg.

AOSD'11 conference

Another interesting conference is coming up: The International Conference on Aspect-Oriented Software Development will be held in Porto de Galinhas, Brazil in March 2011. The conference chair is Shigeru Chiba, who is a long-term contributor to reflection and metaprogramming techniques himself, and who has assembled a diverse program committee covering not only core aspect technologies (like AspectJ-influenced approaches), but also explicitly Feature-oriented Programming, Context-oriented Programming, and also metaprogramming and reflection (which have been somewhat neglected in the aspect community for a long time, although they are clearly very relevant), among others. Dynamic languages are also mentioned in the call for research papers, so good papers based on languages like Lisp, Scheme, Smalltalk, and so on, are definitely welcome.

Another interesting element of this conference that I haven't seen before is that there will be two opportunities to submit papers: The first deadline is July 1, 2010, and the second deadline is October 1, 2010. The idea is that papers that fail to get accepted in the first round can be improved by their authors for a second round of reviews. It will be interesting to see if this works out.

International Lisp Conference '10

The International Lisp Conference (ILC'10) is being held again, sooner than expected: It will be held in October 2010 in Reno, Nevada. This year, the conference will be co-located with OOPSLA/SPLASH, which also hosts the Dynamic Language Symposium. So this event is bound to be a very interesting combination. Paper submission for ILC'10 is open, submission deadline is August 1, so there is enough time to submit something. See the call for papers for more information.

Lisp Machine demonstration...

I only now realized that besides the interesting talks and presentations to be given at this year's European Lisp Symposium, there will also be a demonstration of a TI Explorer Lisp Machine. That's pretty cool - I have never seen a Lisp Machine in action, but always wanted to see one, so this will be my first time. Looking forward to that. :)

Ah, yes, here is the link again: European Lisp Symposium, Lisbon, Portugal, May 6-7, 2010.

There will also be presentations by Kent Pitman and Matthias Felleisen whose abstracts sound pretty interesting, and I will try to give an overview of parallel programming in Common Lisp at the symposium as well. Still have to work on the slides for that one...

3rd European Lisp Symposium is very soon!

The third European Lisp Symposium is less than a month away. I have received the following call for participation to redistribute, which I post here for everyone to read.

3rd European Lisp Symposium

May 6-7, 2010, Fundacao Calouste Gulbenkian, Lisbon, Portugal

Call for Participation

Registration for the 3rd European Lisp Symposium (ELS 2010) is now open.

Scope and Programme Highlights

The purpose of the European Lisp Symposium is to provide a forum for the discussion of all aspects of the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate.

As well as presentations of the accepted technical papers and tutorials, the programme features the following highlights:

• Kent Pitman of HyperMeta Inc. will offer reflections on Lisp Past, Present and Future;
  
• Pascal Costanza will lead a tutorial session on Parallel Programming in Common Lisp;
  
• Matthias Felleisen of PLT will talk about languages for creating;
  
• programming languages;
  
• there will be opportunities for attendees to give lightning talks and demos of late-breaking work.
  

Social events

• Symposium banquet (included with registration)
  
• Excursion to Sintra (optional), for six centuries the favourite
  
• Summer residence of the Kings of Portugal, who were attracted by cool climates and the beauty of the town's setting.
  

Programme Chair

Christophe Rhodes, Goldsmiths, University of London, UK

Local Chair

Antonio Leitao, Technical University of Lisbon, Portugal

Programme Committee

• Marco Antoniotti, Universita Milano Bicocca, Italy
  
• Giuseppe Attardi, Universita di Pisa, Italy
  
• Pascal Costanza, Vrije Universiteit Brussel, Belgium
  
• Irene Anne Durand, Universite Bordeaux I, France
  
• Marc Feeley, Universite de Montreal, Canada
  
• Ron Garret, Amalgamated Widgets Unlimited, USA
  
• Gregor Kiczales, University of British Columbia, Canada
  
• Antonio Leitao, Technical University of Lisbon, Portugal
  
• Nick Levine, Ravenbrook Ltd, UK
  
• Scott McKay, ITA Software, Inc., USA
  
• Peter Norvig, Google Inc., USA
  
• Kent Pitman, PTC, USA
  
• Christian Queinnec, Universite Pierre et Marie Curie, France
  
• Robert Strandh, Universite Bordeaux I, France
  
• Didier Verna, EPITA Research and Development Laboratory, France
  
• Barry Wilkes, Citi, UK
  
• Taiichi Yuasa, Kyoto University, Japan
  

Registration

Registration is open and costs EUR120 (EUR60 for students) until 22nd April, and EUR200 (EUR120 for students) afterwards.

Registration includes a copy of the proceedings, coffee breaks, and the symposium banquet. Accommodation is not included.

Filtered functions

I am very excited that I can finally annouce a public release of filtered functions, an extension of generic functions that Charlotte Herzeel, Jorge Vallejos, and myself have developed some time ago and that we are very excited about because it seems to be quite powerful in a number of very different scenarios. It took a while to release filtered functions, because it is a quite non-trivial extension of generic functions and requires a CLOS MOP implementation that is compliant with the AMOP specification to quite a deep level. Therefore, this required some serious preparation in the form of a much improved Closer to MOP library, that I released today as well.

You can find filtered functions and Closer to MOP at the Closer project website. Below you will find a general overview of the concept.

Filtered functions are an extension of generic functions, extended with a filtering step where the arguments received by a generic function are mapped to other values based on user-defined mapping functions. Those filtered values are then used to perform the actual selection and execution of applicable methods. Nevertheless, the methods that are eventually executed see the original objects as received by the generic function, and not the filtered ones.

Here are some examples to illustrate the expressive power of filtered functions.

Factorial

In order to be able to use filtered functions, we need to have filter functions that map received arguments to values that we actually want to base our dispatch on. For the factorial function, we want to distinguish between negative and positive numbers, and the number zero. For that we can just use the Common Lisp function SIGNUM that returns +1 for positive numbers, -1 for negative numbers, and just 0 for the number 0. The filtered function FAC can thus be defined as follows.

(define-filtered-function fac (n)
  (:filters (:sign #'signum)))

DEFINE-FILTERED-FUNCTION is exactly like DEFGENERIC, except that it can also define one or more filters. Here, it defines a filter with the name :SIGN wich specifices that the function SIGNUM is to be used for filtering.

We can now define methods for FAC:

(defmethod fac :filter :sign ((n (eql +1)))
  (* n (fac (- n 1))))

(defmethod fac :filter :sign ((n (eql 0)))
  1)

(defmethod fac :filter :sign ((n (eql -1)))
  (error "Fac not defined for negative numbers."))

Here, we use the qualifiers :FILTER :SIGN in the method definitions to indicate that we indeed want to use the :SIGN filter for method selection. We then use EQL specializers to ensure that the method definitions are applicable for the three different cases that SIGNUM yields. Remember that the method bodies always see the original arguments, not the filtered ones, and this is why the FAC methods can do the correct computations.

State pattern

Filtered functions can be used to dispatch methods based on the state of an argument passed to a filtered function, which enables expressing State-like idioms. Assume the following simple CLOS class is defined for implementing a stack.

(defconstant +stack-size+ 10)

(defclass stack ()
  ((contents :initform (make-array +stack-size+)
             :reader stack-contents))
   (index :initform 0
          :accessor stack-index)))

Instances of this class have three different states: Such a stack can either be empty, or full, or anywhere in between (in 'normal' state). We can express this as a function that recognizes the state of a stack.

(defun stack-state (stack)
  (cond ((<= (stack-index stack) 0) 'empty)
        ((>= (stack-index stack) +stack-size+) 'full)
        (t 'normal)))

It is now straightforward to use stack-state in a filter named :state for the typical stack operations.

(define-filtered-function stack-push (stack value)
  (:filters (:state #'stack-state)))

(define-filtered-function stack-pop (stack)
  (:filters (:state #'stack-state)))

(define-filtered-function stack-emptyp (stack)
  (:filters (:state #'stack-state)))

We can now group the behavior of a stack according to its different states. Note that for 'normal' state, we do not need to mention the use of any filter here, because the methods are not specialized on anything specific anyway. (Filtered functions always allow for 'regular' methods alongside the filtered methods.)

;;; Normal state

(defmethod stack-push (stack value)
  (setf (aref (stack-contents stack)
              (stack-index stack))
        value)
  (incf (stack-index stack)))

(defmethod stack-pop (stack)
   (decf (stack-index stack))
   (aref (stack-contents stack)
         (stack-index stack)))

(defmethod stack-emptyp (stack)
  nil)

;;; Empty state

(defmethod stack-pop :filter :state ((stack (eql 'empty)))
  (error "Stack is empty."))

(defmethod stack-emptyp :filter :state ((stack (eql 'empty)))
  t)

;;; Full state

(defmethod stack-push :filter :state ((stack (eql 'full)) value)
  (error "Stack is full."))

Note that we used a derived state function here, that determines the state of the stack based on some of its other properties. Since filter functions can be any functions, we could also use the reader of a slot as a filter function, and thus have the behavior of a filtered function depend on the explicit state of an object.

Filtered functions can do a lot more: As already mentioned, they can use more than one filter; filter functions can see all the arguments a generic function receives; and filters can be guarded, which means that methods that use a particular filter may be completely ignored if the arguments don't fulfil a certain predicate. You can read the paper Filtered Dispatch that I co-authored with Charlotte Herzeel, Jorge Vallejos and Theo D'Hondt for a more thorough introduction, background information and semantics, and which also includes an extensible metacircular Lisp interpreter as an example, based on implementing EVAL as a filtered function.