Peter Siebel - Practical Common Lisp

But if that were still true, then (funcall (lambda (...) ...))would be illegal because FUNCALL is a function and the normal evaluation rule for a function call would require that the LAMBDA expression be evaluated. However, late in the ANSI standardization process, in order to make it possible to implement ISLISP, another Lisp dialect being standardized at the same time, strictly as a user-level compatibility layer on top of Common Lisp, a LAMBDA macro was defined that expands into a call to FUNCTION wrapped around the LAMBDA expression. In other words, the following LAMBDA expression:

(lambda () 42)

exands into the following when it occurs in a context where it evaluated:

(function (lambda () 42)) ; or #'(lambda () 42)

This makes its use in a value position, such as an argument to FUNCALL, legal. In other words, it's pure syntactic sugar. Most folks either always use #' before LAMBDA expressions in value positions or never do. In this book, I always use #'.

Dynamic variables are also sometimes called special variables for reasons you'll see later in this chapter. It's important to be aware of this synonym, as some folks (and Lisp implementations) use one term while others use the other.

Early Lisps tended to use dynamic variables for local variables, at least when interpreted. Elisp, the Lisp dialect used in Emacs, is a bit of a throwback in this respect, continuing to support only dynamic variables. Other languages have recapitulated this transition from dynamic to lexical variables—Perl's localvariables, for instance, are dynamic while its myvariables, introduced in Perl 5, are lexical. Python never had true dynamic variables but only introduced true lexical scoping in version 2.2. (Python's lexical variables are still somewhat limited compared to Lisp's because of the conflation of assignment and binding in the language's syntax.)

Actually, it's not quite true to say that all type errors will always be detected—it's possible to use optional declarations to tell the compiler that certain variables will always contain objects of a particular type and to turn off runtime type checking in certain regions of code. However, declarations of this sort are used to optimize code after it has been developed and debugged, not during normal development.

As an optimization certain kinds of objects, such as integers below a certain size and characters, may be represented directly in memory where other objects would be represented by a pointer to the actual object. However, since integers and characters are immutable, it doesn't matter that there may be multiple copies of "the same" object in different variables. This is the root of the difference between EQ and EQL discussed in Chapter 4.

In compiler-writer terms Common Lisp functions are "pass-by-value." However, the values that are passed are references to objects. This is similar to how Java and Python work.

The variables in LET forms and function parameters are created by exactly the same mechanism. In fact, in some Lisp dialects—though not Common Lisp— LET is simply a macro that expands into a call to an anonymous function. That is, in those dialects, the following:

(let ((x 10)) (format t "~a" x))

is a macro form that expands into this:

((lambda (x) (format t "~a" x)) 10)

Java disguises global variables as public static fields, C uses externvariables, and Python's module-level and Perl's package-level variables can likewise be accessed from anywhere.

If you specifically want to reset a DEFVAR ed variable, you can either set it directly with SETF or make it unbound using MAKUNBOUND and then reevaluate the DEFVAR form.

The strategy of temporarily reassigning *standard-output* also breaks if the system is multithreaded—if there are multiple threads of control trying to print to different streams at the same time, they'll all try to set the global variable to the stream they want to use, stomping all over each other. You could use a lock to control access to the global variable, but then you're not really getting the benefit of multiple concurrent threads, since whatever thread is printing has to lock out all the other threads until it's done even if they want to print to a different stream.

The technical term for the interval during which references may be made to a binding is its extent . Thus, scope and extent are complementary notions—scope refers to space while extent refers to time. Lexical variables have lexical scope but indefinite extent, meaning they stick around for an indefinite interval, determined by how long they're needed. Dynamic variables, by contrast, have indefinite scope since they can be referred to from anywhere but dynamic extent. To further confuse matters, the combination of indefinite scope and dynamic extent is frequently referred to by the misnomer dynamic scope .

Though the standard doesn't specify how to incorporate multithreading into Common Lisp, implementations that provide multithreading follow the practice established on the Lisp machines and create dynamic bindings on a per-thread basis. A reference to a global variable will find the binding most recently established in the current thread, or the global binding.

This is why dynamic variables are also sometimes called special variables .

If you must know, you can look up DECLARE , SPECIAL , and LOCALLY in the HyperSpec.

Several key constants defined by the language itself don't follow this convention—not least of which are T and NIL . This is occasionally annoying when one wants to use tas a local variable name. Another is PI , which holds the best long-float approximation of the mathematical constant pi.

Some old-school Lispers prefer to use SETQ with variables, but modern style tends to use SETF for all assignments.

Look up DEFSETF , DEFINE-SETF-EXPANDER for more information.

The prevalence of Algol-derived syntax for assignment with the "place" on the left side of the =and the new value on the right side has spawned the terminology lvalue , short for "left value," meaning something that can be assigned to, and rvalue , meaning something that provides a value. A compiler hacker would say, " SETF treats its first argument as an lvalue."

C programmers may want to think of variables and other places as holding a pointer to the real object; assigning to a variable simply changes what object it points to while assigning to a part of a composite object is similar to indirecting through the pointer to the actual object. C++ programmers should note that the behavior of =in C++ when dealing with objects—namely, a memberwise copy—is quite idiosyncratic.