`Understanding Common Lisp' book available for download at Franz site
Paolo Amoroso
"Understanding Common Lisp"
David J. Cooper, Jr.
August, 2000
http://www.franz.com/resources/educational_resources/cooper.book.pdf
Thanks to the author and Franz for making it available.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
David J. Cooper
> This new book can be downloaded from the Franz site:
>
> "Understanding Common Lisp"
> David J. Cooper, Jr.
> August, 2000
> http://www.franz.com/resources/educational_resources/cooper.book.pdf
>
Note that the currently posted pdf file is rough -- it uses Type 3
fonts which cause a much larger than necessary pdf file, and a
rough-looking output. I have produced a smaller cleaner pdf file with
Type 1 fonts, and Franz Inc. should be posting that Real Soon
Now. Note also that the new title of the book is "Basic Lisp
Techniques," and as the title indicates it is pretty basic stuff.
-dave
--
David J. Cooper Jr, Chief Engineer Genworks International
dco...@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com
Paolo Amoroso
wrote:
> Paolo Amoroso <amo...@mclink.it> writes:
[...]
> > http://www.franz.com/resources/educational_resources/cooper.book.pdf
[...]
> rough-looking output. I have produced a smaller cleaner pdf file with
> Type 1 fonts, and Franz Inc. should be posting that Real Soon
> Now. Note also that the new title of the book is "Basic Lisp
Will the new version of the book be available at the same URL?
Duane Rettig
> Paolo Amoroso <amo...@mclink.it> writes:
>
> > This new book can be downloaded from the Franz site:
> >
> > "Understanding Common Lisp"
> > David J. Cooper, Jr.
> > August, 2000
> > http://www.franz.com/resources/educational_resources/cooper.book.pdf
> >
>
> Note that the currently posted pdf file is rough -- it uses Type 3
> fonts which cause a much larger than necessary pdf file, and a
> rough-looking output. I have produced a smaller cleaner pdf file with
> Type 1 fonts, and Franz Inc. should be posting that Real Soon
> Now. Note also that the new title of the book is "Basic Lisp
> Techniques," and as the title indicates it is pretty basic stuff.
The above url should have been updated now, as of this (Friday) morning.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Paolo Amoroso
wrote:
> rough-looking output. I have produced a smaller cleaner pdf file with
> Type 1 fonts, and Franz Inc. should be posting that Real Soon
Just out of curiosity: which Lisp-based markup language did you use to
produce the document? You mention it in section C.1. Is it GWL?
David J. Cooper
Paolo Amoroso <amo...@mclink.it> writes:
>
> Just out of curiosity: which Lisp-based markup language did you use to
> produce the document? You mention it in section C.1. Is it GWL?
>
By the way, the new PDF which is currently posted is still flawed -- I
managed to mess up the top and bottom margins so there is a huge top
margin and no bottom margin. A repaired PDF should be there within a
few days.
The Lisp-based markup language is just a temporary thing I threw
together, in the spirit of JKF's htmlgen, but the implementation is
not nearly as elegant -- a bit messy for public consumption unless
someone is _really_ interested. I hope to turn it into (or find)
something ``more real'' for the next go-around. To give you an idea
here is an example piece of the source text for the book, using the
markup language:
((:subsection :title "Lisp Syntax Simplicity")
"One of the nicest things about Lisp is the simplicity and
consistency of its syntax. What we have covered so far pertaining to the
evaluation of arguments to Functions is "
(:emph "just about everything you need to know")
" about the syntax. The rules for Macros are very similar, with
the primary difference being that all the arguments of a Macro are not
necessarily evaluated at the time the Macro is called --- they can be
transformed into something else first.
This simple consistent syntax is a welcome relief from other widely used
languages such as "
(:indexed "C")
", "
(:indexed "C++")
", "
(:indexed "Java")
", "
(:indexed "Perl")
", "
"and "
(:indexed "Python")
". These languages claim to use a ``more natural'' ``"
(:indexed "infix")
"'' syntax, but in reality their syntax is a confused
mixture of "
(:indexed "prefix")
", "
(:indexed "infix")
", and "
(:indexed "postfix")
". They use infix only for the simplest arithmetic
operations such as "
(:verbatim "2 + 2")
" and "
(:verbatim "3 * 13")
"and use postfix in certain cases such as "
(:verbatim "i++")
" and "
(:verbatim "char*")
"But mostly they actually use a prefix syntax much the same as
Lisp, as in: "
(:verbatim "split(@array, \":\");")
"So, if you have been programming in these other languages, you
have been using prefix notation all along, but may not have
noticed it. If you look at it this way, the prefix notation of Lisp will
seem much less alien and, in fact, downright natural to you.")
Chris Page
illustrate something unrelated, but this passage caught my eye.]
in article pmqzolg...@lang.genworks.com, David J. Cooper at
dco...@genworks.com wrote on 2000.09.10 12:29 PM:
> One of the nicest things about Lisp is the simplicity and consistency of its
> syntax...This simple consistent syntax is a welcome relief from other widely
> used languages...These languages claim to use a ``more natural'' syntax, but
> in reality their syntax is a confused mixture of prefix, infix, and postfix.
> They use infix only for the simplest arithmetic operations...But mostly they
> actually use a prefix syntax much the same as Lisp...
One thing to consider about the whole "Lisp syntax" issue is that simplicity
and orthogonality can sometimes be too "smooth", making them less expressive
than more complex and irregular solutions. Always keep in mind the
possibility that a convoluted syntax like that of C++ may actually have some
merits.
--
Chris Page
Mac OS Guy
Palm, Inc.
let mail-to = concatenate( "Chris Page <page", "@", "best.com>");
Erik Naggum
| One thing to consider about the whole "Lisp syntax" issue is that
| simplicity and orthogonality can sometimes be too "smooth", making
| them less expressive than more complex and irregular solutions.
| Always keep in mind the possibility that a convoluted syntax like
| that of C++ may actually have some merits.
This is a really odd argument. Are you confused into thinking that
every CL object is expressed via explicit calls to the type
constructor, as in a list? Once you learn to _exploit_ Common Lisp,
you find that the syntax has rough edges on that smooth surface.
When you learn to write your own syntax-supporting reader functions,
you find that you don't even need one-character prefix dispatch that
basically read like lists. (I'm counting #x as a one-character
prefix on x, too, treating the # just like "meta" represented by the
escape key.) If you like more syntax, go for it! No language is
more flexible in the syntax department than Common Lisp is.
If other syntaxes had had merit _to_Lisp_programmers_, they would
have been implemented and most probably shared amongst them.
I think you should try to understand how come people don't argue for
the merits of the syntax of C++, but rather for not deviating from
it. A hint: It hurts like hell to learn C++ and so those who do it
while not aware of their predicament become psychologically scarred
and feel the heavy pressure of deep angst at the sight of foreign
syntaxes, fearing more torture and abuse before they can understand.
#:Erik
--
If this is not what you expected, please alter your expectations.
David Bakhash
> * Chris Page <pa...@best.NOSPAM.com>
> | One thing to consider about the whole "Lisp syntax" issue is that
> | simplicity and orthogonality can sometimes be too "smooth", making
> | them less expressive than more complex and irregular solutions.
> | Always keep in mind the possibility that a convoluted syntax like
> | that of C++ may actually have some merits.
>
> This is a really odd argument.
I agree that it is odd as well, but I think I see where he's coming
from.
For example. Lately, I did a job using Perl/SQL. I had to generate
lots of SQL calls (strings), and they often looked like this:
$dbh->do("
INSERT INTO Transactions (authNumber,
authAmount,
ccAccountId,
merchantId,
userId,
authDateTime)
VALUES (${authNumber},
${authAmount},
${ccAccountId},
${merchantId},
${userId},
${CURRENT_DATETIME})
");
And I really liked being able to name the variables inside the string,
and have them just come out right. We discussed this once, and you
mentioned that there was some kind of security issue here, but I don't
see it. It's possible that a user (hacker, etc.) somehow enters a
string into a text field that later gets ``evaluated'', where some
$var inside the string gets interpolated unexpectedly. But that can
easily be avoided if you know what you're doing, and arn't sloppy.
Of course, there are solutions in Common Lisp for such things, and one
of the better ones I've seen is the Common SQL stuff from Harlequin,
which looks something like (from their docs):
[select [foo] [bar *]
:from '([baz] [bar])
:where [or [= [foo] 3]
[> [baz.quux] 10]]]
-->
#<SQL-QUERY
"(SELECT FOO,BAR.* FROM BAZ,BAR
WHERE ((FOO = 3)
OR (BAZ.QUUX > 10)))">
But with all the SQL extensions there are, it's sometimes awkward, and
I don't really like it as much as straight SQL, and neither would most
people who know Common Lisp and SQL, but had never seen this before.
Of course, the reason this stuff exists is that #'FORMAT is not a
friendly solution for such tasks. The Perl interpolating strings are
a more natural fit. If you compare my Perl example with the
{#\[,#\]}, you may see why a lot of people like these kinds of
features. Perl is a good example of it because it has so many
syntactic extensions whereas CL doesn't (though in CL you can add
them). In Perl, unfortunately, you can't really add other syntaxes,
as far as I know. But what's already there is quite powerful,
provided you know how to use it. Examples are:
o (0 .. $n) -> list of nos.
o while ($line = <FILE>) { ...;}
o the whole `$_' thing
Now that I've veered off the topic, let me try to get back.
What I'm saying is that Common Lisp is very highly extensible and
adaptable, but in a very roundabout, wholesome, elegant way. Perl, on
the other hand, seems to have zillions of random features,
syntactricks*, libraries, etc. that just make doing very complicated
things feasible. It's a hodge-podge, but what you can do -- and
what's been done -- is quite amazing. And Perl seems to have added
very Lisp-like features, like:
o letting functions set variables if used as l-values
o extending the function syntax so that users can define
functions with built-in-like syntax
o anonymous function references (very much like lambda).
In fact, in Perl, you can pass around functions, apply them, bind
and unbind them to variables, lexically and dynamically redefine
functions bound to symbols, etc.
For years I would complain that Perl didn't have the equivalent of
#'EQUALP hashtables with respect to strings (i.e. case-insensitive
keys). Then someone used Perl's tie() to implement this. It turns
out that tie() in Perl lets you do things that I don't know are
possible in Common Lisp, except maybe with symbol macros, but even
then I'm not sure.
Common Lisp thankgodfully refuses to add random little features that
add a lot of heinosity to the syntax, and make it harder to
implement. But the result of that is that languages like Perl, that
are willing to throw in lots of random stuff, become as adaptable (if
not more) as Common Lisp.
Anyway, this is not an argument, and I'm not taking a side. I'm just
telling my story here: that a language which in some ways is on the
opposite end of the spectrum as Common Lisp, has its merrits. Of
course, I also often argue that Perl is more similar to CL than C,
C++, and Java.
dave
---
*this word derived from "syntactrickery", from one of Erik's posts
Mark-Jason Dominus
David Bakhash <ca...@alum.mit.edu> wrote:
>For example. Lately, I did a job using Perl/SQL. I had to generate
>lots of SQL calls (strings), and they often looked like this:
>
> $dbh->do("
>INSERT INTO Transactions (authNumber,
> authAmount,
> ccAccountId,
> merchantId,
> userId,
> authDateTime)
>VALUES (${authNumber},
> ${authAmount},
> ${ccAccountId},
> ${merchantId},
> ${userId},
> ${CURRENT_DATETIME})
>");
>
>And I really liked being able to name the variables inside the string,
>and have them just come out right.
I think you've picked a bad example. Even in Perl this is the Wrong
Way to Do It, for resaons of performance and security. The Right Way
is just as convenient.
See
http://www.perl.com/pub/1999/10/DBI.html#Don_t_do_This
for details.
David Bakhash
> In article <m3og1ub...@cadet.dsl.speakeasy.net>,
> David Bakhash <ca...@alum.mit.edu> wrote:
> >For example. Lately, I did a job using Perl/SQL. I had to generate
> >lots of SQL calls (strings), and they often looked like this:
> I think you've picked a bad example. Even in Perl this is the Wrong
> Way to Do It, for resaons of performance and security. The Right Way
> is just as convenient.
>
> See
>
> http://www.perl.com/pub/1999/10/DBI.html#Don_t_do_This
>
> for details.
I don't think I agree with this completely. And the "right" way to do
it is not necessarily more or less convenient, and is definitely not
really easier to read. Let's see. From the URL you forwarded:
| Don't do This
|
| People are always writing code like this:
|
| while ($lastname = <>) {
| my $sth = $dbh->prepare("SELECT * FROM people
| WHERE lastname = '$lastname'");
| $sth->execute();
| # and so on ...
| }
first off, that's not what my code looks like. I never put a variable
inside single quotes; instead, I used
$var = $dbh->quote($var)
before using it.
| This is a bad thing to do for three reasons.
|
| First, prepare calls can take a long time. The database server has to
| compile the SQL and figure out how it is going to run the query. If
| you have many similar queries, that is a waste of time.
The prepare call is going to have to send a SQL string regardless.
Either Perl does the interpolation with the `?' notation, or with just
nesting the variable(s) in the string. It's not a major difference in
terms of time. It's actually close to nothing.
Also, I almost NEVER run SQL code inside a loop like in the example.
That's poor design, and can almost always be avoided, especially in
situations where you're on-line and want things done fast.
In batch processing situations, it really doesn't make much of a
difference, though. I can see how the ? notation might speed this up,
and I do use it sometimes. But in my post I was making a point.
| Second, it will not work if $lastname contains a name like O'Malley or
| D'Amico or some other name with an '. The ' has a special meaning in
| SQL, and the database will not understand when you ask it to prepare a
| statement that looks like
|
| SELECT * FROM people WHERE lastname = 'O'Malley'
|
| It will see that you have three 's and complain that you don't have a
| fourth matching ' somewhere else.
again, I said that I properly quoted the SQL string before passing it.
| Finally, if you're going to be constructing your query based on a user
| input, as we did in the example program, it's unsafe to simply
| interpolate the input directly into the query, because the user can
| construct a strange input in an attempt to trick your program into
| doing something it didn't expect. For example, suppose the user enters
| the following bizarre value for $input:
|
| x' or lastname = lastname or lastname = 'y
|
| Now our query has become something very surprising:
|
| SELECT * FROM people WHERE lastname = 'x' or lastname =
| lastname or lastname = 'y'
|
yeah. Also something that is handled properly when you quote the SQL
before passing it to the do() method.
If you follow the guidelines I state above, there are no security
issues, and likely no performance issues either, unless the prepare()
method doesn't need to know the substituded values for the ?'s. But
even that will go mostly unnoticed.
dave