Peter Siebel - Practical Common Lisp

(remove-method #'initialize-instance

(find-method #'initialize-instance () (list (find-class 'bank-account))))

Of course, providing an accessor function doesn't really limit anything since other code can still use SLOT-VALUE to get at slots directly. Common Lisp doesn't provide strict encapsulation of slots the way some languages such as C++ and Java do; however, if the author of a class provides accessor functions and you ignore them, using SLOT-VALUE instead, you had better know what you're doing. It's also possible to use the package system, which I'll discuss in Chapter 21, to make it even more obvious that certain slots aren't to be accessed directly, by not exporting the names of the slots.

One consequence of defining a SETF function—say, (setf foo)—is that if you also define the corresponding accessor function, fooin this case, you can use all the modify macros built upon SETF , such as INCF , DECF , PUSH , and POP , on the new kind of place.

The "variable" names provided by WITH-SLOTS and WITH-ACCESSORS aren't true variables; they're implemented using a special kind of macro, called a symbol macro , that allows a simple name to expand into arbitrary code. Symbol macros were introduced into the language to support WITH-SLOTS and WITH-ACCESSORS , but you can also use them for your own purposes. I'll discuss them in a bit more detail in Chapter 20.

The Meta Object Protocol (MOP), which isn't part of the language standard but is supported by most Common Lisp implementations, provides a function, class-prototype, that returns an instance of a class that can be used to access class slots. If you're using an implementation that supports the MOP and happen to be translating some code from another language that makes heavy use of static or class fields, this may give you a way to ease the translation. But it's not all that idiomatic.

In other words, Common Lisp doesn't suffer from the diamond inheritance problem the way, say, C++ does. In C++, when one class subclasses two classes that both inherit a member variable from a common superclass, the bottom class inherits the member variable twice, leading to no end of confusion.

Of course, most folks realize it's not worth getting that worked up over anything in a programming language and use it or not without a lot of angst. On the other hand, it's interesting that these two features are the two features in Common Lisp that implement what are essentially domain-specific languages using a syntax not based on s-expressions. The syntax of FORMAT 's control strings is character based, while the extended LOOP macro can be understood only in terms of the grammar of the LOOP keywords. That one of the common knocks on both FORMAT and LOOP is that they "aren't Lispy enough" is evidence that Lispers really do like the s-expression syntax.

Readers interested in the pretty printer may want to read the paper "XP: A Common Lisp Pretty Printing System" by Richard Waters. It's a description of the pretty printer that was eventually incorporated into Common Lisp. You can download it from ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-1102a.pdf.

To slightly confuse matters, most other I/O functions also accept T and NIL as stream designators but with a different meaning: as a stream designator, T designates the bidirectional stream *TERMINAL-IO* , while NIL designates *STANDARD-OUTPUT* as an output stream and *STANDARD-INPUT* as an input stream.

This variant on the ~Cdirective makes more sense on platforms like the Lisp Machines where key press events were represented by Lisp characters.

Technically, if the argument isn't a real number, ~Fis supposed to format it as if by the ~Ddirective, which in turn behaves like the ~Adirective if the argument isn't a number, but not all implementations get this right.

Well, that's what the language standard says. For some reason, perhaps rooted in a common ancestral code base, several Common Lisp implementations don't implement this aspect of the ~Fdirective correctly.

f you find "I saw zero elves" to be a bit clunky, you could use a slightly more elaborate format string that makes another use of ~:*like this:

(format nil "I saw ~[no~:;~:*~r~] el~:*~[ves~;f~:;ves~]." 0) ==> "I saw no elves."

(format nil "I saw ~[no~:;~:*~r~] el~:*~[ves~;f~:;ves~]." 1) ==> "I saw one elf."

(format nil "I saw ~[no~:;~:*~r~] el~:*~[ves~;f~:;ves~]." 2) ==> "I saw two elves."

This kind of problem can arise when trying to localize an application and translate human-readable messages into different languages. FORMAT can help with some of these problems but is by no means a full-blown localization system.

Throws or raises an exception in Java/Python terms

Catches the exception in Java/Python terms

In this respect, a condition is a lot like an exception in Java or Python except not all conditions represent an error or exceptional situation.

In some Common Lisp implementations, conditions are defined as subclasses of STANDARD-OBJECT , in which case SLOT-VALUE , MAKE-INSTANCE , and INITIALIZE-INSTANCE will work, but it's not portable to rely on it.

The compiler may complain if the parameter is never used. You can silence that warning by adding a declaration (declare (ignore c))as the first expression in the LAMBDA body.

Of course, if IF wasn't a special operator but some other conditional form, such as COND , was, you could build IF as a macro. Indeed, in many Lisp dialects, starting with McCarthy's original Lisp, COND was the primitive conditional evaluation operator.

Well, technically those constructs could also expand into a LAMBDA expression since, as I mentioned in Chapter 6, LET could be defined—and was in some earlier Lisps—as a macro that expands into an invocation of an anonymous function.