Well, yeah, but the chapter on strings is chapter 5. Shapiro doesn't start with strings, he starts with numbers, which I think is a catastrophic mistake. When I say start with strings I mean start with strings. Actually, start with characters, i.e. start by pointing out that the fundamental units of computation when you interact with a computer using a keyboard are things like these:
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
~ ! @ # $ % ^ & * ( ) _ - + = { } [ ] : ; " ' < > , . / ?
Then talk about how stringing these things together in sequences can denote different things, but that these denotations are just conventions. For example, by convention we denote strings using double quotes:
"This is a string"
Note that there are two ways you can look at the above. You can see it as a sequence of 18 characters that starts and ends with quotes, or you can see it as a sequence of 16 characters that starts with T and ends with g. This ambiguity leads to a whole host of problems, not least of which is that if you want to write a string that includes a double-quote mark you now have to somehow indicate that the embedded double-quote does not denote the end of the string but it intended to be a constituent of the string, and the fact that the same character is used to denote both the start and end of strings was actually a catastrophic design error but we're stuck with it now because of the weight of history. (The Right Way to denote strings is with balanced quotes «like this» but that ship sailed a long time ago.)
And then, once the student understands strings, you can start talking about how some strings, like "123", stand for numbers, and how this is also just a convention, because strings like "123,000.00" look like numbers to any educated human but don't stand for numbers in any programming language except Microsoft Excel again because history, yada yada yada.
The point is, numbers are really really complicated, even more complicated than symbols, and they are definitely not the right place to start teaching any of this notwithstanding that this is where everyone starts.
Shapiro does a very good job of emphasizing the difference between an object and its multiple printed-representations (S-expression). He promises to do that in the Preface, and delivers.
Computer Science once used to be the same thing as Numerical Analysis; that has left a deep imprint on the education. Here is how we use Lisp: (+ 2 2) evaluates to 4.
> Shapiro does a very good job of emphasizing the difference between an object and its multiple printed-representations (S-expression).
I think that is debatable. When he introduces S-expressions in chapter 3 it is in the context of a chapter on lists, not S-expressions. (In fact, he doesn't have a chapter on S-expressions!) And he doesn't actually define S-expression, he only defines "list S-expression" and leaves it up to the reader to infer that numbers are S-expressions -- or is it the printed representation of a number that is an S-expression? Shapiro never actually says. So is 123 a number? Or is it an S-expression denoting a number? Are these the same thing? Again, Shapiro never actually says. AFAICT, at no point in the book does he ever make it explicit that an S-expression is a string, and in particular, a string which is a serialization of a data structure.
It makes sense to you because you already know how it works. You need to read it with your beginner-mindset hat on to see the problems.
But I had read that with an actual beginner's* mindset. Since then, not once have I had the thought that Shapiro misled about this or that.
In the Preface there is a paragraph Package Systems, S-expressions and Forms where Shapiro explains what those mean. It's clear that he's not using S-expression just to refer to compound syntax. The paragraph concludes:
In this book, I distinguish the S-expression from the form—the printed representation from the object—in Chapter 1 and continue making the distinction consistently and explicitly through the entire book.
There is only small matter there in that Common Lisp uses form for an expression in an evaluated context. What Shapiro wants there is "distinguish the S-expression from the (internal) expression".
Some of that paragraph also rather belongs in the book proper rather than the Preface.
Chapter 3 does not leave it to the reader to infer that number tokens are S-expressions. It says so explicitly: "According to this definition (1 2 3.3 4) is a list S-expression, since 1, 2, 3.3 and 4 are S-expressions (denoting numbers)". That's just re-iteration; prior material in the book hammered the point that the printed representation of any object is a S-expression.
---
* Well, a Lisp beginner's mindset. Not a programming beginner's mindset. If you already know things like that compilers scan textual numeric tokens, turning them into binary numbers, that colors the interpretation.
> prior material in the book hammered the point that the printed representation of any object is a S-expression
Yes, he does say that. The problem is that this is wrong. There are many printed forms of objects that are not S-expressions. In fact, these are so common that CL has some fairly extensive infrastructure for dealing with these cases.
S-expressions have nothing to do with printing (except insofar as Lisp makes an effort to maintain read-print consistency in some circumstances), they have to do with reading. They are operational at the beginning of the read-eval-print loop, not at the end.
Yes, obviously, most of those chapters are concerned with what we type into the text file or REPL, which is often something that was not ever printed.
There are many examples of #< notation in the book, but, as far as I can see, no remarks are made about what that means, or even that the contents of #<...> are implementation-specific and may appear differently. I don't see any discussions of the concept of print-read consistency, and so on: that objects can sometimes be printed in a way that either cannot be read at all, or worse, that produces a different object, like the #: notation.
It would help the book to talk early about print-read consistency. What it is, when do we have it, when do we not have it, in what situations can we provide it for ourselves when we don't have it, etc.
Compiling Lisp isn't covered in the book; there is only a cursory mention of compile-file. The omission is a lost opportunity to discuss Lisp's "interactive approach" to compilation. In compilation there is the issue of literals: what kinds of objects are externalizable. That relates to printing because externalization is a kind of printing. Compile-file has to print the literal objects into some kind of bits in the file, which then recover a similar object.
The word "image" doesn't appear in the book; it doesn't look as if image saving is mentioned anywhere.
a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 ~ ! @ # $ % ^ & * ( ) _ - + = { } [ ] : ; " ' < > , . / ?
Then talk about how stringing these things together in sequences can denote different things, but that these denotations are just conventions. For example, by convention we denote strings using double quotes:
"This is a string"
Note that there are two ways you can look at the above. You can see it as a sequence of 18 characters that starts and ends with quotes, or you can see it as a sequence of 16 characters that starts with T and ends with g. This ambiguity leads to a whole host of problems, not least of which is that if you want to write a string that includes a double-quote mark you now have to somehow indicate that the embedded double-quote does not denote the end of the string but it intended to be a constituent of the string, and the fact that the same character is used to denote both the start and end of strings was actually a catastrophic design error but we're stuck with it now because of the weight of history. (The Right Way to denote strings is with balanced quotes «like this» but that ship sailed a long time ago.)
And then, once the student understands strings, you can start talking about how some strings, like "123", stand for numbers, and how this is also just a convention, because strings like "123,000.00" look like numbers to any educated human but don't stand for numbers in any programming language except Microsoft Excel again because history, yada yada yada.
The point is, numbers are really really complicated, even more complicated than symbols, and they are definitely not the right place to start teaching any of this notwithstanding that this is where everyone starts.