Weitz - Common Lisp Recipes: a Problem-Solution Approach

Common Lisp Recipes: a Problem-Solution Approach — read online for free the complete book (whole text) full work

Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Common Lisp Recipes: a Problem-Solution Approach" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.

Light

Font size:

↓

↑

Georgia Tahoma Arial Verdana

Reset

Interval:

↓

↑

Bookmark:

Make

1234567...163

Edmund Weitz 2016

Edmund Weitz Common Lisp Recipes 10.1007/978-1-4842-1176-2_1

Chapter 1: Symbols and Packages

Edmund Weitz 1

(1)

Hamburg, Germany

Symbols are one of the most important building blocks of Common Lisp . Many other programming languages either dont have symbols, or if they have them, they are just one of many data types. But in Lisp, symbols play a central role because they are used to name things like variables and functions, are indispensable in macros, but are also objects in their own right. Thus, they deserve some attention.

Although symbols are superficially easy to get, they are complicated compound objects under the hood, so if you want to use them in advanced ways, a deeper understanding of them and their interaction with packages is necessary. Thats what main parts of this chapter are about.

Theres one thing you definitely should not use symbols for: dont use them when strings (see ), thats not what they are for. You will occasionally find older code where symbols are used for everything ; but that is most likely because it was written for a Lisp dialect that didnt have strings or because it was written by someone who didnt know better.

Also, code that creates new symbols automatically and constructs their names by gluing things together smells fishy in my opinion. You should at least think twice before doing that.

Note that for didactical reasons the recipes in this chapter generally use the functional interface to the package system. In practice, you will almost always use DEFPACKAGE in your code, as for example on pages 27 and 29.

1-1. Understanding the Role of Packages and the Symbol Nomenclature

Problem

Symbols can be accessible , inherited , internal , present , and so on. They have a home package but can live in several different packages at the same time or in none at all. This can all be pretty confusing at first, but it is vital to develop a good understanding of how packages and symbols interact in order to get the finer points.

Solution

Well work through the various notions and interdependencies using an example. Lets create three new packages using these forms and then dissect what we get:

How It Works

We now have a situation that can be depicted graphically, like so:

Each of the four large boxes above is a package; the smaller rectangles denote symbols. We see the three packages, P1 through P3 , which we explicitly created, and the CL (or COMMON-LISP ) package, which is already there when we start our Lisp image and of whose many symbols we only show a sample of four.

A package is a container of symbols (thats why they are drawn as boxes holding the symbol rectangles); and it is probably fair to say that the main job of packages is to help us find symbols and to organize them into groups. This can also be put differently: packages can help us name and find symbols, but symbols can have an existence on their own; that is, without packages. (As well see in Recipes .)

Symbols are usually created automatically (by the Lisp reader; see ) because it creates a new internal symbol of the package.

Of course, most of the time symbols are not created because, when it reads them, the Lisp system firsts checks if they are already there; that is, whether they are accessible using the name and (implicit or explicit) package prefix you provided. So, in the following situation (assuming you just started your Lisp image)

when your Lisp reads foo it is as if it had read cl-user::foo because (as the prompt shows) the CL-USER package is the current package. Because no symbol with the name "FOO" is accessible via the package CL-USER , a new symbol (with that name and in that package) is created (viz. interned into the package).

When your Lisp now reads foo again , a symbol described by this sequence of characters is available (the one that was just created) and is returned.

In our example code from page 2 we didnt create any symbols this way but we created them implicitly or explicitly through the DEFPACKAGE forms. Lets see what we got this way:

• Symbols are either present in a package or not. In our picture, the symbols present in a package are those that are contained within the surrounding box.
• Symbols become present in a package either if a new symbol is interned (see above) or if an existing symbol is imported .
  The DEFPACKAGE form for P3 , for example, explicitly interned a symbol named ALPHA and explicitly imported the symbol named DELTA from the P2 package.
• When a symbol is imported into a package, the effect is that the same symbol is now present in (at least) two different packages. In the picture, we used dashed lines to show identity; that is, symbols connected with dashed lines are actually the same symbol and symbols not connected are really different symbols.
• Once a symbol is present in a package, it can only be removed using the function UNINTERN (see Recipe ).
• If a symbol is present in a package, it can be exported from that package. This means that it can now be accessed using only one colon between the packages and the symbols name. Exported symbols are shown with a gray background in our picture.
  For example, the package P1 exports the symbol CHARLIE , but not the symbol ALPHA . We didnt explicitly intern CHARLIE , but because we instructed the system to export it, it had to be present and was thus created (and interned) automatically.
• Exported symbols are called external and the other ones are called internal .
• A package can also have inherited symbols. This happens if a package uses another package. All external symbols of the used package become inherited symbols of the package using this package. Inherited symbols are not shown directly in our picture but rather by means of the arrows on the right that show which packages use which other packages.
  For example, package P3 uses package P2 and thus P2:ECHO is an inherited symbol of P3 . Likewise, P3 also uses CL and thus all of the 978 exported symbols of CL (see footnote on page 19) become inherited symbols of P3 . You can thus refer to P2:ECHO as P3::ECHO and to CL:ABS as P3::ABS .
• Inheritance is not transitive. The fact that P3 uses P2 and P2 in turn uses P1 does not mean that the symbol P1:CHARLIE is an inherited symbol of P3 .
  P3 has its own symbol named CHARLIE , which was implicitly created because it was exported, but this symbol is different from P1:CHARLIE .
• A symbol is accessible in a package (in other words, it can be found through that package) if it is either present or inherited in that package.
  As accessibility means that a symbol can be found in a package by name, it implies that no two different accessible symbols can have the same name. This would be called a name conflict . To provoke such a conflict, try something like this:

  

Next page

1234567...163

Light

Font size:

↓

↑

Georgia Tahoma Arial Verdana

Reset

Interval:

↓

↑

Bookmark:

Make

Similar books «Common Lisp Recipes: a Problem-Solution Approach»

Look at similar books to Common Lisp Recipes: a Problem-Solution Approach. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.

Peter Siebel

Practical Common Lisp

Mark Watson

Loving Common Lisp, or the Savvy Programmer’s Secret Weapon

Vsevolod Domkin

Programming Algorithms in Lisp: Writing Efficient Programs with Examples in ANSI Common Lisp

Miller

Programming Clojure

Conrad Barski M.D

Land of Lisp: learn to program in Lisp, one game at a time!

Seibel

Practical Common Lisp

Edmund Weitz

Common Lisp Recipes: A Problem-Solution Approach

Daniel Holden.

Build Your Own Lisp: Learn C and Build Your Own Programming Language

David S. Touretzky

Common LISP: A Gentle Introduction to Symbolic Computation

Conrad Barski

Land of Lisp: Learn to Program in Lisp, One Game at a Time!

Bob Glickstein

Writing GNU Emacs Extensions

Peter Seibel

Practical Common Lisp

Discussion, reviews of the book Common Lisp Recipes: a Problem-Solution Approach and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.