Common Lisp Cookbook - proposal and request for comments

431 views
Skip to first unread message

Dr. Edmund Weitz

unread,
Jan 24, 2002, 4:52:13 AM1/24/02
to
I think most of you will agree that once you're hooked on Common Lisp
you realize that you've found a language which has things to offer
that no competitor has, so I won't discuss this any
further. Nevertheless, CL is also a language that is somewhat hard for
newcomers, especially for those who've used other, more widespread
languages before: I come from the Perl/C/Java camp (and this is how I
pay my rent) and there are myriads of _simple_ tasks that I could
implement in these languages without thinking while I would have to
work hard to get them done in CL. This is what this posting is about:

I now that many c.l.l regulars despise Perl, but I hope you'll agree
that the Perl community has a couple of things that we can learn
from. The one thing that I'm going to talk about here is the famous
(?) Perl Cookbook (see <http://www.oreilly.com/catalog/cookbook/>), a
nice little book that provides concise, elegant and instructive
answers to seemingly simple questions like "You need to find the
number of days between two dates or times" or "You want to get a list
of filenames similar to MS-DOS's *.* and Unix's *.h", or "You want to
access or modify just a portion of a string, not the whole thing". If
you've been using Lisp since the day you were born this might seem
trivial to you, but judging from my experience - and from many
questions I've read in this newsgroup - many of these simple tasks
seem to be harder than they should be in CL (and they are usually not
dealt with in the standard literature, i.e. Graham, Norvig,
Winston/Horn, and so on).

This posting is a proposal for a community effort to provide a "Common
Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources
for Java, Python and other languages). It'll provide 'recipes' that'll
help you in implementing mundane stuff and thus enabling you to get
more comfortable with the language as well as giving you more time to
think about the stuff that's really hard (and would probably be a pain
to do in other languages).

I hereby volunteer to organize/maintain this project if enough people
are willing to help. I will also be able to host the project (see
below) if this will be the agreed-upon way to do it. Following are a
couple of thoughts about the Cookbook project. I hope many people will
have something to say about it - additions, corrections, improvements,
suggestions, comments are welcome (and should be directed to the
newsgroup and not to my email address).

[Disclaimers: 1. I'm rather new to CL. I'm lightyears away from being
the Tom Christiansen of Common Lisp, so I will need the help of as
many people as possible. (A newbie might be able to ask the right
questions but somebody has to answer them...) 2. I have a family to
feed, so I can't guarantee to keep any terms.]

Having said that, here comes the main stuff:

0. What it is and what it isn't.

- This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
AutoLisp, or whatever.

- The target audience are people who are new to (Common) Lisp - people
who have just discovered the language and are willing to learn it.

- The Cookbook will provide small code snippets as answers to
frequently asked questions usually beginning with "How do I..." (see
above for examples). The code should ideally be accompanied with a
discussion of how it works and what has to be paid attention to plus
pointers to relevant chapters in books, online articles or the
CLHS. (The standard article in the Perl Cookbook has four parts:
"Problem", "Solution", "Discussion", "See also". An example can be
found at
<http://www.oreilly.com/catalog/cookbook/chapter/ch08.html>.)

- The project does not aim to supplant introductory books or the
HyperSpec. People who use the Cookbook are expected to know the
language basics and to consult the CLHS if necessary.

- The Cookbook should be agnostic to operating systems and
implementations if possible. It will surely be necessary to provide
information that is specific to a certain OS or vendor (especially
if we're talking about non-ANSI stuff) but it would be nice if
readers had a choice between different versions.

- Contributions to the Cookbook aren't expected to be exhaustive or
worthy a Pulitzer Price. On the contrary - I am convinced that at
least thirty percent of the typical newbie questions can be answered
by pointing them to a specific function entry in the CLHS (or - even
better - by providing a one-line solution).

- Due to the nature of this there will be some intersection with the
c.l.l FAQ (recently revived by Christophe Rhodes at
<http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html>), but I think
these projects are different enough to warrant two distinct
documents.

- This'll be an ongoing collaborative effort and it will be perfectly
OK to just post a good question. Let someone else take care of the
answer.

1. Content

Here's a quick sketch of the content in very rough form. It's
assembled from the O'Reilly Books, the CLHS, and from postings to this
newsgroup.

- Basics: Installation, Loading and Compiling
- Numbers: BIGNUMS, rationals, complex numbers
- Strings / Regular Expressions
- Dates and Times
- Arrays
- Hash Tables
- Lists/Conses
- Structures
- CLOS
- Other data structures: Btrees, Queues, Linked Lists
- Iteration: LOOP, SERIES, MAP functions
- Searching and Sorting
- Input and Output, Streams, FORMAT, the Lisp Reader
- Conditions, Error Handling
- File Access, File Contents, Directories
- Packages
- Defsystem
- Debugging, Profiling, Advice
- Database Access
- Sockets
- Internet Protocols, Web Serving
- Multi-Processing, Multi-Threading
- FFI, Extending and Embedding CL
- Communicating with other processes
- GUI
- I18N
- XML
- MOP

This is of course open to discussion. I'm sure I've missed
something. Also, I'm not sure about the correct order and I'm aware of
the fact that I've mixed rather basic stuff with advanced topics.

Let me repeat that I think the basic stuff is important and this'll be
what the Cookbook is about. Many Lisp newcomers have an idea how to
implement something in their preferred programming language but they
tend to feel lost if they're to choose from the wealth of built-in
functions and data types that CL has to offer.

2. Infrastructure / How to do it

2.1. The first thing that comes to mind (and has been mentioned here
already) is CLiki. The good thing about it is that it's already
there and we can simply start hacking in questions and
answers. But I think it might be better if we had some means to
organize the whole project - providing for ways to easily
re-structure the whole document and for automatic generation of
different formats like HTML, TeX, PDF...

2.2. That's why I think a custom-tailored database-backed website
would be the best solution. As with CLiki, everybody should be
able to add content or change what's there already (maybe after
registering once with his name and email address). I would
volunteer to set up such a thing (although I'd currently write it
in mod_perl/DBI - shame on me - rather than in CL/USQL) and
provide a server to host it.

[This could be somewhat similar to the Python Cookbook at
<http://aspn.activestate.com/ASPN/Cookbook/Python>. I haven't
looked at every detail but it seems to be OK.]

2.3. As an alternative one could start a Sourceforge project to host a
couple of Texinfo files. Contributors would have to use CVS.

3. License

This will be a collaborative effort, so we'll have to find a license
that seems fair to everyone who contributes code and advice. I'm not
familiar with Open Source Documentation Licenses. What do you think
would be the best one and why?

4. "Prior Art"

I'm pretty sure that most of the stuff that would go into this
Cookbook has already been posted to c.l.l at least once by very
knowledgeable people, it's just a matter of finding and organizing
it. Would you think it'll be OK to take a code snippet from
groups.google.com, put it into the Cookbook and add a reference like
"posted to comp.lang.lisp by Donald Duck at Dec 12, 1996 as
<news:m3y9mze...@disney.com>" or do you see any legal
restrictions?

OK, I hope this is enough to start a discussion and to solicit more
input. I'm really willing to do this - not only because I'm a good guy
(ahem) but mainly because I think it'll be a very good way to improve
my own knowledge of Common Lisp. It'd be great if many others would
join this project for whatever reasons they might have.

Thanks for your time,
Edi.

Dr. Edmund Weitz

unread,
Jan 24, 2002, 8:09:26 AM1/24/02
to
e...@agharta.de (Dr. Edmund Weitz) writes:

> 3. License
>
> This will be a collaborative effort, so we'll have to find a license
> that seems fair to everyone who contributes code and advice. I'm not
> familiar with Open Source Documentation Licenses. What do you think
> would be the best one and why?

Sorry for answering to myself but this might be interesting:

<http://slashdot.org/article.pl?sid=02/01/23/2022235&mode=thread&threshold=1>

Edi.

Marc Battyani

unread,
Jan 24, 2002, 8:55:42 AM1/24/02
to

"Dr. Edmund Weitz" <e...@agharta.de> wrote in message
news:m3it9so...@bird.agharta.de...
[snip...]

> Having said that, here comes the main stuff:
>
> 0. What it is and what it isn't.
>
> - This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
> AutoLisp, or whatever.
>
> - The target audience are people who are new to (Common) Lisp - people
> who have just discovered the language and are willing to learn it.

Don't forget those who learned Lisp in some recent (or distant) past but are
coming back to it.

[snip...]

> - Due to the nature of this there will be some intersection with the
> c.l.l FAQ (recently revived by Christophe Rhodes at
> <http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html>), but I think
> these projects are different enough to warrant two distinct
> documents.

If they end up having too much intersection it will be possible to merge
them anyway.

[snip...]

> 2.1. The first thing that comes to mind (and has been mentioned here
> already) is CLiki. The good thing about it is that it's already
> there and we can simply start hacking in questions and
> answers. But I think it might be better if we had some means to
> organize the whole project - providing for ways to easily
> re-structure the whole document and for automatic generation of
> different formats like HTML, TeX, PDF...

sexpr ?

> 2.2. That's why I think a custom-tailored database-backed website
> would be the best solution. As with CLiki, everybody should be
> able to add content or change what's there already (maybe after
> registering once with his name and email address). I would
> volunteer to set up such a thing (although I'd currently write it
> in mod_perl/DBI - shame on me - rather than in CL/USQL) and
> provide a server to host it.

Argh! mod_perl.... Please use mod_lisp or any CL web server ;-)

Marc


Dr. Edmund Weitz

unread,
Jan 24, 2002, 9:26:08 AM1/24/02
to
"Marc Battyani" <Marc.B...@fractalconcept.com> writes:

> Argh! mod_perl.... Please use mod_lisp or any CL web server ;-)

One of my servers has mod_lisp installed and I'm experimenting with
CMUCL there. However, if I would write the application with mod_lisp
and CL I'd need _much_ more time for it (while mod_perl is my
bread-and-butter currently). Installing UncommonSQL alone might take
me a couple of hours... :(

[This is a FreeBSD machine, no CCLAN and apt-get install available.]

Once the Cookbook is finished all this will be much easier of
course. Version 2.0 will be hosted by a CL web server... :)

Cheers,
Edi.

Marc Battyani

unread,
Jan 24, 2002, 10:10:25 AM1/24/02
to

"Dr. Edmund Weitz" <e...@agharta.de> wrote in message
news:m3d6zza...@dyn138.dbdmedia.de...

> "Marc Battyani" <Marc.B...@fractalconcept.com> writes:
>
> > Argh! mod_perl.... Please use mod_lisp or any CL web server ;-)
>
> One of my servers has mod_lisp installed and I'm experimenting with
> CMUCL there. However, if I would write the application with mod_lisp
> and CL I'd need _much_ more time for it (while mod_perl is my
> bread-and-butter currently). Installing UncommonSQL alone might take
> me a couple of hours... :(

Why do you want a SQL database ? For now you have 0 article so you don't
need an SQL database. Even when you have lots of articles, you won't need an
SQL database.
As I wrote in the previous post, you can use sexprs to store the data. Or
some CLOS objects in a hash table or in a list. There are lots of quick
start solutions.

To start you just need a server, apache, mod_lisp and an HTML generation
macro and that's it.
Start with an in memory database saved as an ascii file (remember Lisp has a
nice reader). It's better to have a working solution in a few days and then
to refine it when it is a huge success.

Then you can put in it the first article : How to write a successful web
application in Lisp in 3 days...

Marc


Pierre R. Mai

unread,
Jan 24, 2002, 10:27:11 AM1/24/02
to
e...@agharta.de (Dr. Edmund Weitz) writes:

> This posting is a proposal for a community effort to provide a "Common
> Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources
> for Java, Python and other languages). It'll provide 'recipes' that'll
> help you in implementing mundane stuff and thus enabling you to get
> more comfortable with the language as well as giving you more time to
> think about the stuff that's really hard (and would probably be a pain
> to do in other languages).

I think this is a very good proposal indeed, and highly refreshing,
after all the constant whining that has been posted here during the
last couple of weeks. I'll add a couple of comments below:

> - The target audience are people who are new to (Common) Lisp - people
> who have just discovered the language and are willing to learn it.

I think it wouldn't hurt to let the focus expand as needed, to include
not quite so new people, who are still willing to learn common idioms,
etc. There are quite a number of known idioms for slightly
advanced/specialized stuff, which would profit from being presented in
a cookbook/recipe like style, like MOP-stuff, etc.

> 2.1. The first thing that comes to mind (and has been mentioned here
> already) is CLiki. The good thing about it is that it's already
> there and we can simply start hacking in questions and
> answers. But I think it might be better if we had some means to
> organize the whole project - providing for ways to easily
> re-structure the whole document and for automatic generation of
> different formats like HTML, TeX, PDF...

It might be useful to start off with CLiki (possibly on a separate
site), and expand the mark-up stuff, and reorganization facilities...

> 4. "Prior Art"
>
> I'm pretty sure that most of the stuff that would go into this
> Cookbook has already been posted to c.l.l at least once by very
> knowledgeable people, it's just a matter of finding and organizing
> it. Would you think it'll be OK to take a code snippet from
> groups.google.com, put it into the Cookbook and add a reference like
> "posted to comp.lang.lisp by Donald Duck at Dec 12, 1996 as
> <news:m3y9mze...@disney.com>" or do you see any legal
> restrictions?

Legally, the stuff posted to newsgroups is covered by copyright laws,
although the application of copyright law to Usenet is probably not
very well understood. I.e. one would presume that certain rights are
implicitly granted by posting, like e.g. the right to redistribute
and copy for the purposes of dissemination on Usenet servers. There
are also the obvious rights granted under fair-use, but one of the
problems with this is that the relation of quoted and unquoted amounts
are taken into consideration, and it is easy to fall afoul of this
requirement with Usenet postings, which are already quite small.

On the whole I'd advise that you get the permission of the poster
(either for an individual posting, or for all postings on c.l.l by the
given poster) prior to inclusion, since this is the best way to cover
yourself, and it might also lead to further interesting input from the
poster, e.g. by pointing out better, or more relevant code in another
posting/source, or by informing the poster of the existence of your
project, which might lead to the poster participating more directly,
or giving you pointers to other interesting articles in the past or
the future.

You might want to contact Paolo Amoroso, who has been doing excellent
work as the editor/creator of the EncyCMUCLopedia, and who will
probably be able to give you more advice on this, and related matters.

Including pointers to the original article is also very important from
the POV of the user, since it gives him the ability to read relevant
parts of the whole thread that give him more context and background on
the why of that particular solution. This prevents the cookbook
approach from degenerating into a simple clipboard to copy from
without understanding, but as a valuable starting point for a journey
that results in deeper insight into the language, and the problem and
solution spaces surrounding a particular question.

Regs, Pierre.

--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein

Marc Spitzer

unread,
Jan 24, 2002, 11:28:14 AM1/24/02
to
In article <0135468F4F467E47.8DC05578...@lp.airnews.net>

, Marc Battyani wrote:
>
> "Dr. Edmund Weitz" <e...@agharta.de> wrote in message
> news:m3d6zza...@dyn138.dbdmedia.de...
>> "Marc Battyani" <Marc.B...@fractalconcept.com> writes:
>>
>> > Argh! mod_perl.... Please use mod_lisp or any CL web server ;-)
>>
>> One of my servers has mod_lisp installed and I'm experimenting with
>> CMUCL there. However, if I would write the application with mod_lisp
>> and CL I'd need _much_ more time for it (while mod_perl is my
>> bread-and-butter currently). Installing UncommonSQL alone might take
>> me a couple of hours... :(
>

If you are looking for a caned app type of solution, take a look
at openacs.org. It looks like what you want in the first draft of
the site is already there:
sql back end(postgres and oracle)
message boards
administrative interface, create/modify/delete message boards ...
full text search

I have installed it a few times to play with and have gotten it running
on freebsd. I would be willing to help install/manage it.

A couple of possible issues:
it uses aolserver not apache
tcl is the scripting language

marc

Christophe Rhodes

unread,
Jan 24, 2002, 11:37:32 AM1/24/02
to
"Marc Battyani" <Marc.B...@fractalconcept.com> writes:

> > - Due to the nature of this there will be some intersection with the
> > c.l.l FAQ (recently revived by Christophe Rhodes at
> > <http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html>), but I think
> > these projects are different enough to warrant two distinct
> > documents.
>
> If they end up having too much intersection it will be possible to merge
> them anyway.

Absolutely -- I'd welcome contributors over here too; time is
limited... :)

I do want to get the FAQ up to postable state, but, alas, the real
world is intervening at the moment.

Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

Paolo Amoroso

unread,
Jan 24, 2002, 12:06:16 PM1/24/02
to
On 24 Jan 2002 16:27:11 +0100, "Pierre R. Mai" <pm...@acm.org> wrote:

> e...@agharta.de (Dr. Edmund Weitz) writes:
>
> > This posting is a proposal for a community effort to provide a "Common
> > Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources

[...]


> > it. Would you think it'll be OK to take a code snippet from
> > groups.google.com, put it into the Cookbook and add a reference like
> > "posted to comp.lang.lisp by Donald Duck at Dec 12, 1996 as
> > <news:m3y9mze...@disney.com>" or do you see any legal
> > restrictions?

[...]


> You might want to contact Paolo Amoroso, who has been doing excellent
> work as the editor/creator of the EncyCMUCLopedia, and who will
> probably be able to give you more advice on this, and related matters.

Quite simple. For each batch of newsgroup or mailing list postings from a
same author that I plan to include in a version of the EncyCMUCLopedia, I
contact the author asking for permission, and including all material for
his reference and convenience. Then I include in the EncyCMUCLopedia
distribution a copy of each posting with full headers as received by my
mail/newsreader, adding a blurb such as "included with permission" in each
index entry.

As Pierre suggests, I have found that contacting authors provides valuable
additional feedback on the material I am interested in.

As for useful tools with which to maintain the Cookbook, I suggest Edmund
to have a look at the SBCL Internals Documentation project, which has
similar technical requirements and is based on CLiki technology:

http://ww.telent.net/sbcl-internals/index


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

novice106

unread,
Jan 24, 2002, 1:50:05 PM1/24/02
to
"Dr. Edmund Weitz" <e...@agharta.de> wrote in message
news:m3it9so...@bird.agharta.de...

[...]

> OK, I hope this is enough to start a discussion and to solicit more
> input. I'm really willing to do this - not only because I'm a good guy
> (ahem) but mainly because I think it'll be a very good way to improve
> my own knowledge of Common Lisp. It'd be great if many others would
> join this project for whatever reasons they might have.

This will be extremely useful for people like me who know something of the
Lisp language but have little experience using it for daily work. I
currently use CMUCL for experimenting with ideas in an Emacs/ILISP buffer,
but I'd like to go beyond that.

I think one of the first hurdles is understanding the package system and
installing new 'modules' (for want of correct terminology). People quite
often complain that the free Lisp implementations lack GUI toolkit support,
database access and so on. It's obviously not true. The packages are out
there, but the installation instructions, if present, often assume prior
knowledge of how Lisp packages work, how they're loaded, how they're used,
etc.

I confess with some embarrassment that I don't know anything about this, and
have not found any idiot-proof instructions. Whilst I could probably install
any package through trial and error, I do think that Common Lisp's way of
handling packages and installing/loading of extensions is sufficiently
different from other languages to merit some basic explanation. Even simple
concepts like "saving an image", which experienced Lisp users naturally take
for granted, are alien to most people who come to Lisp from other languages.
In my opinion, this would be a good place to start.

If we had a page with detailed step-by-step instructions on how to set up,
say, Clisp or CMUCL with a commonly requested configuration, eg. complete
with bindings to GTK+ and MaiSQL, it would give the user the background s/he
needs to install other packages when the time comes.

I think your project is an excellent idea.
I will certainly be willing to contribute when I can.

Christophe Rhodes

unread,
Jan 24, 2002, 1:23:56 PM1/24/02
to
"novice106" <novi...@yahoo.com.au> writes:

> "Dr. Edmund Weitz" <e...@agharta.de> wrote in message
> news:m3it9so...@bird.agharta.de...
>
> [...]
>
> > OK, I hope this is enough to start a discussion and to solicit more
> > input. I'm really willing to do this - not only because I'm a good guy
> > (ahem) but mainly because I think it'll be a very good way to improve
> > my own knowledge of Common Lisp. It'd be great if many others would
> > join this project for whatever reasons they might have.
>

> If we had a page with detailed step-by-step instructions on how to set up,
> say, Clisp or CMUCL with a commonly requested configuration, eg. complete
> with bindings to GTK+ and MaiSQL, it would give the user the background s/he
> needs to install other packages when the time comes.

Well, we sort of do, but currently it starts with
"1. Install Debian..."
because that is the only "Operating Environment" that
common-lisp-controller, or any equivalent to my knowledge, runs
on. Counterexamples are welcome :)

Thaddeus L Olczyk

unread,
Jan 24, 2002, 6:45:22 PM1/24/02
to
On 24 Jan 2002 10:52:13 +0100, e...@agharta.de (Dr. Edmund Weitz)
wrote:

Stuff about the language written by Larry "Should Be Lined Up Against
A " Wall cut, allthough I'm tempted.

>This posting is a proposal for a community effort to provide a "Common
>Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources
>for Java, Python and other languages). It'll provide 'recipes' that'll
>help you in implementing mundane stuff and thus enabling you to get
>more comfortable with the language as well as giving you more time to
>think about the stuff that's really hard (and would probably be a pain
>to do in other languages).
>

While I think it should be vast enough so that people can open to a
page and find a solution close to a problem they have, I don't think
the focus should just be a "recipe" thing.

Rather the focus should be on getting people "thinking in lisp" well
enough so that they can answer similar questions on their own.

>I hereby volunteer to organize/maintain this project if enough people
>are willing to help. I will also be able to host the project (see
>below) if this will be the agreed-upon way to do it. Following are a
>couple of thoughts about the Cookbook project. I hope many people will
>have something to say about it - additions, corrections, improvements,
>suggestions, comments are welcome (and should be directed to the
>newsgroup and not to my email address).
>

>


>Having said that, here comes the main stuff:
>
>0. What it is and what it isn't.
>
>- This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
> AutoLisp, or whatever.
>

I believe the lions share of jobs ( and I do believe getting a "lisp
job" is the goal of many of the newer people ) are in the "embedded
language" business where Lisp is used as an embedded scripting
language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
on ACL is the best thing.

Instead I think you should say that ACL solutions are prefered over
Scheme solutions or Emacs Lisp solutions. But in the end the best
solutions are ones that can be used by as many possible
implementations as is possible. ( You might hafve to tweak them
though. )

>- The target audience are people who are new to (Common) Lisp - people
> who have just discovered the language and are willing to learn it.
>

Maybe also people who use lisp but rarely, say once a month. So some
things fade.
I also think the focus should be on people with some coding exerience
( at least a year in another language ) rather then someone whose
first language is lisp.

>- The Cookbook will provide small code snippets as answers to
> frequently asked questions usually beginning with "How do I..." (see
> above for examples). The code should ideally be accompanied with a
> discussion of how it works and what has to be paid attention to plus
> pointers to relevant chapters in books, online articles or the
> CLHS. (The standard article in the Perl Cookbook has four parts:
> "Problem", "Solution", "Discussion", "See also". An example can be
> found at
> <http://www.oreilly.com/catalog/cookbook/chapter/ch08.html>.)
>

I think that many problems may involve multiple solutions.
For example: quick hacks versus more complicated solutions which run
more efficiently.
Another might be to a question like:
How do I find the extension of a file?
Solution 1: use pathname-type.
Solution2: Describe how to parse the filename.

The reason is that people seeing this question might be wondering
howto get the extension, but others might be thinking:
" I need to parse this string in a way similar to the way that you
parse a filename to get the extension. The answer to that question
might be give me the answer to my question."

>- The project does not aim to supplant introductory books or the
> HyperSpec. People who use the Cookbook are expected to know the
> language basics and to consult the CLHS if necessary.
>

Here I would disagree. The CLHS is a standard. Standards are mean for
language implementors, not for users. Therefore they are often
unreadable. An answer to the question:
"How do I write a while loop?"
might be to look up the "loop" command in the CLHS.
At that point I expect the reader to give up on Lisp and take up VB.
At the very least ClTl2 should be considered a supplimental manual.

I think this is all very wrong. It reads like the table of contents of
a lisp book, and will therefore reflect many lisp books ( and their
problems ).
A very partial version might be something like:

1) Non Lisp problems.
a) Looping.
i) How do I write a "For Loop"?
ii) How do I write a "while Loop"?
iii) How do I write a "repeat-until Loop"?
iv) Write an inifinite loop?
v) Return from the infinte loop in iV.
b) Files and Directories
i) How do I get a list of files in a directory?
ii) How do I get a list of directories in a directory?
iii) How do I read in a file?
Iv) How do I write to a file?
2) Lisp problems
1) List manipulation
i) How do I add something to a list?
a) At the biginnning.
b) At the end.
c) In the middle.
ii) How do I find an element in a list"
iii) How do I remove an element for a list?
2) What is the equivalent of an
associated array/hash table/dictionary/map?
i) How do I look up an association?
ii) How do I look up a reverse association?
iii) How do I create an association?

>2. Infrastructure / How to do it
>
>2.1. The first thing that comes to mind (and has been mentioned here
> already) is CLiki. The good thing about it is that it's already
> there and we can simply start hacking in questions and
> answers. But I think it might be better if we had some means to
> organize the whole project - providing for ways to easily
> re-structure the whole document and for automatic generation of
> different formats like HTML, TeX, PDF...
>

While I hate to promote Smalltalk. You might want to check out
swiki. It seems to be thew best wiki server around, and includes
the ability to lock pages ( as well as very advanced Administration ).
The one weakness is that it doesn't have a startup/shutdown script
needed by UNIX systems.

You might also want to check out ThoughtWeaver. This is a Wiki variant

Jim Coplien used to to collect a set of patterns on the organisational
structure of a development group. One thing Thought Weaver did was
collect the web pages into a pdf file for people to download the
latest snapshot.

Wiki's would be OK, but please keep away from
TheStupidWikiWayOfNamingThings.
At first it's cute but gets annoying after a while.
There are several free wiki's which don't use that format.

>
>3. License
>
>This will be a collaborative effort, so we'll have to find a license
>that seems fair to everyone who contributes code and advice. I'm not
>familiar with Open Source Documentation Licenses. What do you think
>would be the best one and why?
>

There is exactly one postgress book out there. When it first came out
it was downloadable from the guys web site. He was distributing it
under some open source license. The Hunt and Thomas Book "Practical
Ruby" has a freely downloadable version too. ( In fact it comes in
many formats. )

>4. "Prior Art"
>
>I'm pretty sure that most of the stuff that would go into this
>Cookbook has already been posted to c.l.l at least once by very
>knowledgeable people, it's just a matter of finding and organizing
>it. Would you think it'll be OK to take a code snippet from
>groups.google.com, put it into the Cookbook and add a reference like
>"posted to comp.lang.lisp by Donald Duck at Dec 12, 1996 as
><news:m3y9mze...@disney.com>" or do you see any legal
>restrictions?
>

This may sound sleasy, but if you only take the snippet then I don't
believe there will ber any problem. If you have doubts change the
variable and function names.

As an example, an answer to the question "How do you read a file a
line at a time?" might read:

(with-open-file (stream file)
(do ((line ( read-line stream) (read-line stream nil 'eof))
((eq line ' eof) return-value)))
(process-line line)))

Do you think anyone should get credit for that?
After all about a dozen people might have posted something similar.

BTW if you use something like a wiki then pages should have phases.
The initial phase would be a general discussion of different
approaches to solve a proble. The consolidation phase should be
when people stop discussion and start consolidating the page into a
clear answer. The final phase is when the solution is done and that
page is locked.

Thaddeus L Olczyk

unread,
Jan 24, 2002, 6:58:23 PM1/24/02
to
On Fri, 25 Jan 2002 05:50:05 +1100, "novice106"
<novi...@yahoo.com.au> wrote:

>I think one of the first hurdles is understanding the package system and
>installing new 'modules' (for want of correct terminology). People quite
>often complain that the free Lisp implementations lack GUI toolkit support,
>database access and so on. It's obviously not true. The packages are out
>there, but the installation instructions, if present, often assume prior
>knowledge of how Lisp packages work, how they're loaded, how they're used,
>etc.

Last weekend I tried to install lispdebug for CLisp.
Apparently the maintainer of lispdebug stopped maintaining the
CLisp version ( this is a guess ) and the package system changed so
that CLisp no longer installs.
I've gone over to the CLisp mail-list and been trying to get some
help, but things have started to get testy over there. ( I'm try to
not let the tone get to hot. )

dj special ed

unread,
Jan 24, 2002, 11:53:10 PM1/24/02
to
Excellent! I these are all topics that we would love to see addressed
from the "pragmatic" programmer's perspective--especially those topics
that are never formally addressed.

-dj

> - Basics: Installation, Loading and Compiling

> - Strings / Regular Expressions
> - Dates and Times

> - File Access, File Contents, Directories

> - Other data structures: Btrees, Queues, Linked Lists

> - CLOS


> - Iteration: LOOP, SERIES, MAP functions

> - Input and Output, Streams, FORMAT, the Lisp Reader
> - Conditions, Error Handling

> - Packages
> - Defsystem
> - Debugging, Profiling, Advice
> - Database Access
> - Sockets
> - Internet Protocols, Web Serving
> - Multi-Processing, Multi-Threading
> - FFI, Extending and Embedding CL
> - Communicating with other processes
> - GUI

> - XML

> - Lists/Conses
> - Searching and Sorting
> - Hash Tables
> - Structures
> - Arrays

> - MOP
> - I18N

Alberto Riva

unread,
Jan 25, 2002, 1:08:35 AM1/25/02
to
Dr. Edmund Weitz wrote:
>
> This posting is a proposal for a community effort to provide a "Common
> Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources
> for Java, Python and other languages). It'll provide 'recipes' that'll
> help you in implementing mundane stuff and thus enabling you to get
> more comfortable with the language as well as giving you more time to
> think about the stuff that's really hard (and would probably be a pain
> to do in other languages).

I too think that this is a great project, and I'll be glad to
contribute if (as I hope) it gets off the ground. Just a few comments:

> - This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
> AutoLisp, or whatever.

Agreed.

> - Due to the nature of this there will be some intersection with the
> c.l.l FAQ (recently revived by Christophe Rhodes at
> <http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html>), but I think
> these projects are different enough to warrant two distinct
> documents.

It's good to see that the FAQ is being revived, first of all. I agree
on the "two documents" strategy, but I also think that the two projects
should be coordinated. The FAQ could act as an "entry level" document,
pointing to the relevant sections of the Cookbook when necessary for
people who want more detail. The Cookbook would in turn point to the
CLHS, newsgroup messages, online resources, etc. for even more detailed
info. I also think the FAQ could benefit from a little restructuring:
for example, the first entry in section 4 (Programming Questions) is
about how to write a 'Hello World' program, and the second one deals
with FLET. Quite a big conceptual gap, I'd say...

> 2. Infrastructure / How to do it
>
> 2.1. The first thing that comes to mind (and has been mentioned here
> already) is CLiki. The good thing about it is that it's already
> there and we can simply start hacking in questions and
> answers. But I think it might be better if we had some means to
> organize the whole project - providing for ways to easily
> re-structure the whole document and for automatic generation of
> different formats like HTML, TeX, PDF...
>
> 2.2. That's why I think a custom-tailored database-backed website
> would be the best solution. As with CLiki, everybody should be
> able to add content or change what's there already (maybe after
> registering once with his name and email address). I would
> volunteer to set up such a thing (although I'd currently write it
> in mod_perl/DBI - shame on me - rather than in CL/USQL) and
> provide a server to host it.
>

> 2.3. As an alternative one could start a Sourceforge project to host a
> couple of Texinfo files. Contributors would have to use CVS.

Being one of the many people who use Lisp for database-backed web
applications, I like solutions 1 and 2, but I'm concerned that the time
to design and set up such an environment might be too long, causing the
project to lose momentum. I'd rather see it start in a simple way
(solution 3, or HTML, or even plain text files) than not start at all.

Anyway, thanks for doing this, and let us know when and how we can start
contributing!

--
Alberto Riva
Children's Hospital
Informatics Program

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:18:07 AM1/25/02
to
"Pierre R. Mai" <pm...@acm.org> writes:

> e...@agharta.de (Dr. Edmund Weitz) writes:
>
> > - The target audience are people who are new to (Common) Lisp -
> > people who have just discovered the language and are willing to
> > learn it.
>
> I think it wouldn't hurt to let the focus expand as needed, to
> include not quite so new people, who are still willing to learn
> common idioms, etc. There are quite a number of known idioms for
> slightly advanced/specialized stuff, which would profit from being
> presented in a cookbook/recipe like style, like MOP-stuff, etc.

Sure. My idea of target audience was obviously too narrow. The Perl
Cookbook and similar documents also appeal to people not so new to the
language.

> It might be useful to start off with CLiki (possibly on a separate
> site), and expand the mark-up stuff, and reorganization
> facilities...

I'll take a closer look at CLiki and how it works this weekend.

Thanks for your comments about the legal side of quoting Usenet
postings. I think I'll try to contact the original posters in any
case.

Thanks,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:19:21 AM1/25/02
to
ma...@oscar.eng.cv.net (Marc Spitzer) writes:

> If you are looking for a caned app type of solution, take a look
> at openacs.org. It looks like what you want in the first draft of
> the site is already there:
> sql back end(postgres and oracle)
> message boards
> administrative interface, create/modify/delete message boards ...
> full text search
>
> I have installed it a few times to play with and have gotten it running
> on freebsd. I would be willing to help install/manage it.
>
> A couple of possible issues:
> it uses aolserver not apache
> tcl is the scripting language

Thanks for the hint. I've played around with ACS a while ago. It's
nice but maybe a bit over-done for the Cookbook. Also, the server that
I'm probably going to provide space on is used for other tasks,
including running test applications for clients of mine. It has Apache
with mod_perl and PostgreSQL already running and has to stay that way.

Thanks,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:20:54 AM1/25/02
to
Paolo Amoroso <amo...@mclink.it> writes:

> Quite simple. For each batch of newsgroup or mailing list postings
> from a same author that I plan to include in a version of the
> EncyCMUCLopedia, I contact the author asking for permission, and
> including all material for his reference and convenience. Then I
> include in the EncyCMUCLopedia distribution a copy of each posting
> with full headers as received by my mail/newsreader, adding a blurb
> such as "included with permission" in each index entry.

Thanks. I think this is the way to go. What do you do if you can't
reach the original author anymore?

> As for useful tools with which to maintain the Cookbook, I suggest
> Edmund to have a look at the SBCL Internals Documentation project,
> which has similar technical requirements and is based on CLiki
> technology:
>
> http://ww.telent.net/sbcl-internals/index

I'll take a closer look at it this weekend.

Thanks,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:27:05 AM1/25/02
to
"Marc Battyani" <Marc.B...@fractalconcept.com> writes:

> Why do you want a SQL database ?

I didn't say that I _needed_ it. It's just that it's already there and
I'm working with it every day. It would be a piece of cake to do a
little app in mod_perl/DBI because I'm used to it - that's all.

> For now you have 0 article so you don't
> need an SQL database.

Yeah. But for 0 articles I don't need mod_lisp either... :)

I hope we'll have a couple of articles soon.

> Even when you have lots of articles, you won't need an SQL database.
> As I wrote in the previous post, you can use sexprs to store the
> data. Or some CLOS objects in a hash table or in a list. There are
> lots of quick start solutions.
>
> To start you just need a server, apache, mod_lisp and an HTML
> generation macro and that's it. Start with an in memory database
> saved as an ascii file (remember Lisp has a nice reader). It's
> better to have a working solution in a few days and then to refine
> it when it is a huge success.
>
> Then you can put in it the first article : How to write a successful
> web application in Lisp in 3 days...

Sounds interesting and I haven't thought about this yet. I usually
tend to use SQL databases because they free me from thinking about
things like concurrent access and stuff. Not that I think we'll soon
have dozens of authors committing articles at the same time... :)

Cheers,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:33:20 AM1/25/02
to
"novice106" <novi...@yahoo.com.au> writes:

> I think one of the first hurdles is understanding the package system
> and installing new 'modules' (for want of correct
> terminology). People quite often complain that the free Lisp
> implementations lack GUI toolkit support, database access and so
> on. It's obviously not true. The packages are out there, but the
> installation instructions, if present, often assume prior knowledge
> of how Lisp packages work, how they're loaded, how they're used,
> etc.
>
> I confess with some embarrassment that I don't know anything about
> this, and have not found any idiot-proof instructions. Whilst I
> could probably install any package through trial and error, I do
> think that Common Lisp's way of handling packages and
> installing/loading of extensions is sufficiently different from
> other languages to merit some basic explanation. Even simple
> concepts like "saving an image", which experienced Lisp users
> naturally take for granted, are alien to most people who come to
> Lisp from other languages. In my opinion, this would be a good
> place to start.

Well said. I have the same problems and I would be glad if I could
find a tutorial that not only explains _what_ to do but also _why_ it
is done and what's happening in the background.

Maybe someone with enough knowledge will add this to the Cookbook once
it's started.

Thanks,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:38:53 AM1/25/02
to
Christophe Rhodes <cs...@cam.ac.uk> writes:

> "novice106" <novi...@yahoo.com.au> writes:
>
> > If we had a page with detailed step-by-step instructions on how to
> > set up, say, Clisp or CMUCL with a commonly requested
> > configuration, eg. complete with bindings to GTK+ and MaiSQL, it
> > would give the user the background s/he needs to install other
> > packages when the time comes.
>
> Well, we sort of do, but currently it starts with "1. Install
> Debian..." because that is the only "Operating Environment" that
> common-lisp-controller, or any equivalent to my knowledge, runs
> on. Counterexamples are welcome :)

I think that providing this stuff for Debian is not enough. And by
that I don't mean someone should also build RPMs for Red Hat,
Mandrake, oder SuSE. I think it would be better if the tools needed
for the installation of Lisp extensions and the usual way of using
them would be explained somewhere rather than telling people they'll
just have to type 'apt-get install'.

With most of the GNU stuff it's just './configure && make && make
install' and it usually works. But if it doesn't work, there's enough
tutorial material out there to help you in understanding why it broke
and how to fix it. I think we should work on providing the same level
of documentation for CL.

Thanks,
Edi.

Thom Goodsell

unread,
Jan 25, 2002, 9:25:03 AM1/25/02
to
olc...@interaccess.com (Thaddeus L Olczyk) writes:
>
> While I think it should be vast enough so that people can open to a
> page and find a solution close to a problem they have, I don't think
> the focus should just be a "recipe" thing.
>
> Rather the focus should be on getting people "thinking in lisp" well
> enough so that they can answer similar questions on their own.

Agreed, sort of. I think that providing recipes is fine (or rather,
good), so long as the "Discussion" section points out the Lisp-think
involved. After all, this is supposed to be a collection of easy
solutions to common problems. It should be used in conjunction with,
e.g., Graham's ANSI Common Lisp or PAIP, which will provide plenty of
Lisp-think information.



> >
> >- This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
> > AutoLisp, or whatever.
> >
> I believe the lions share of jobs ( and I do believe getting a "lisp
> job" is the goal of many of the newer people ) are in the "embedded
> language" business where Lisp is used as an embedded scripting
> language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
> on ACL is the best thing.

Can't agree with this one. If we try to cover every Lisp dialect and
Lisp-like dialect this will end up being an unintelligible
nightmare. As it is, much of the stuff in this cookbook will rely on
something like CLOCC to cover implementation-dependent stuff. Trying
to then include intirely new dialect is just way too much, IMHO.



> Instead I think you should say that ACL solutions are prefered over
> Scheme solutions or Emacs Lisp solutions. But in the end the best
> solutions are ones that can be used by as many possible
> implementations as is possible. ( You might hafve to tweak them
> though. )

The point is that one target audience of this book is people who
wouldn't have the foggiest idea of what to tweak.



> >- The project does not aim to supplant introductory books or the
> > HyperSpec. People who use the Cookbook are expected to know the
> > language basics and to consult the CLHS if necessary.
> >
> Here I would disagree. The CLHS is a standard. Standards are mean for
> language implementors, not for users. Therefore they are often
> unreadable.

While I certainly don't think that the CLHS should be the only
reference, I definitely think that it should be referenced. Unlike a
lot of other languages, we have a standard that *is* readable by
users, whatever its intended audience. I think we should show off that
fact. Besides, the CLHS is as close as you can get to a final
authority without buying the actual spec from ANSI.

Thom

--
(map 'string #'(lambda (char) (let ((char-code (char-code char)))
(code-char (if (< 64 char-code 123) (+ (mod (+ 13 char-code) 52) 65)
char-code)))) "Z...@IXG.IUS")

Tim Bradshaw

unread,
Jan 25, 2002, 10:00:42 AM1/25/02
to
> Why do you want a SQL database ? For now you have 0 article so you don't
> need an SQL database. Even when you have lots of articles, you won't need an
> SQL database.

Well said. The only thing you get is transactions and that's hardly
an issue here.

--tim

Bijan Parsia

unread,
Jan 25, 2002, 10:29:23 AM1/25/02
to
On Fri, 25 Jan 2002, novice106 wrote:

[snip]


> I think one of the first hurdles is understanding the package system and
> installing new 'modules' (for want of correct terminology).

Goodness yes! I started my first Common Lisp program using LispWorks. I
wanted to play around with the recent update to CL-XML. Sometimes I get
things to work, and sometimes I done ;) I've made a little bit of progress
on understanding packages (with a little help from the HyperSpec, a little
help from the manuals, and a little help form Norvig, and a whole lot of
pounding my face on the keyboard :)).

The CAPI user manual is a great example of how to hurt a guy like me :) I
went there to try to do a little GUI work. Let me first say that CAPI is
*great*. It's very easy to use overall, and has some nice widgets. I'm
thus far really happy with it.

It would be *perfect* for playing around with Lisp *if* the examples in
the manual didn't bite you hard. For example:

http://www.xanalys.com/software_tools/reference/lwl41/capiuser/CUG_15.HTM
------------
All symbols in this manual are exported from either theCAPI
orCOMMON-LISPpackages unless explicitly stated otherwise. You should use
theCAPI package in your code to access them:

(defpackage "MY-PACKAGE"
(:add-use-defaults t)
(:use "CAPI")
)


This creates and loads a package containing all theCAPI commands required
to try out the examples in this guide
------------

Then on
http://www.xanalys.com/software_tools/reference/lwl41/capiuser/CUG_16.HTM#HEADING16-0

This section shows how easy it is to create a simple window, and how to
include CAPI elements, such as panes, in your window.

1. Type the following in a listener
(make-instance 'interface
:title "My Interface")

(display *)
-----------

Well, there are a bunch of situtions where that code one run. Adding the
CAPI: prefix to the right bits helps. As does an in-package. But, it took
me a while to figure these things out :)

Now, I'm sure even a slightly more experienced person would have had no
trouble (maybe not!). But would those more experienced people have needed
the defpackage snippet in the first place? Why that and not the bit more?

This would be a *terrific* introduction to common lisp. The GUI examples
are *very* satifactory to play with, and they are high reward.

[snip]

> I confess with some embarrassment that I don't know anything about this, and
> have not found any idiot-proof instructions.

Yep. If there is one out there, someone let me know!

> Whilst I could probably install
> any package through trial and error, I do think that Common Lisp's way of
> handling packages and installing/loading of extensions is sufficiently
> different from other languages to merit some basic explanation.

Yep.

> Even simple
> concepts like "saving an image", which experienced Lisp users naturally take
> for granted, are alien to most people who come to Lisp from other languages.
> In my opinion, this would be a good place to start.

That's *not* alien to me (being a Smalltalker) and various things were
non-obvious to me :)

The installation instructions on http://www.cl-xml.org are an example of
something that actually didn't help me a lot (and they're a bit hard to
find). If I get enough control over it, I will certainly submit some.

(No strike on James Anderson! CL-XML looks great, it's just not set up for
XMLers who know little to know CL :))

> I think your project is an excellent idea.
> I will certainly be willing to contribute when I can.

Indeed. If Xanalys is willing, it would be fun to adapt their CAPI guide
to focus more on "learning CL through GUI code" (rather than documenting
CAPI per se).

Cheers,
Bijan Parsia.

Holger Schauer

unread,
Jan 25, 2002, 9:52:06 AM1/25/02
to
On Thu, 24 Jan 2002, Thaddeus L. Olczyk wrote:
> On 24 Jan 2002 10:52:13 +0100, e...@agharta.de (Dr. Edmund Weitz)
> wrote:

A very nice proposal.

> While I think it should be vast enough so that people can open to a
> page and find a solution close to a problem they have, I don't think
> the focus should just be a "recipe" thing.
> Rather the focus should be on getting people "thinking in lisp" well
> enough so that they can answer similar questions on their own.

I guess that it will be hard to keep any focus, given the multiple
author approach, or even worse the idea of using Usenet postings. The
major problem with the latter is arguably the lack of context (when
copying _one_ posting).

>>- This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
>> AutoLisp, or whatever.
>>
> I believe the lions share of jobs ( and I do believe getting a "lisp
> job" is the goal of many of the newer people ) are in the "embedded
> language" business where Lisp is used as an embedded scripting
> language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
> on ACL is the best thing.
> Instead I think you should say that ACL solutions are prefered over
> Scheme solutions or Emacs Lisp solutions. But in the end the best
> solutions are ones that can be used by as many possible
> implementations as is possible. ( You might hafve to tweak them
> though. )

You must be joking or very ignorant of the differences between Common
Lisp, Scheme and Emacs Lisp. Many one-line solutions for Common Lisp
would need a lot of code in either Scheme or ELisp.

>>- The project does not aim to supplant introductory books or the
>> HyperSpec. People who use the Cookbook are expected to know the
>> language basics and to consult the CLHS if necessary.

ACK

> Here I would disagree. The CLHS is a standard. Standards are mean
> for language implementors, not for users. Therefore they are often
> unreadable.

I -- as a user -- find the CLHS to be extremely useful. In fact, it is
by far my major resource when solving problems. And yes, I mostly find
it very readable and its examples very helpful.

> An answer to the question: "How do I write a while
> loop?" might be to look up the "loop" command in the CLHS. At that
> point I expect the reader to give up on Lisp and take up VB.

I am really not sure whether I would include such a question in a
/Cookbook/. But anyway: yes, I would definitely include a reference to
the CLHS. But that doesn't prevent one from giving a small example as
well.

Holger

--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Ja, wir sind die, die vor lauter Baeumen auch noch einen Wald sehen
koennen. Da stehen wir mitten drin und rufen gaaaanz laut zurueck. Das
hat man davon, wenn man laut in den Wald ruft."
-- Friedbert Widmann in de.comp.text.tex

Marco Antoniotti

unread,
Jan 25, 2002, 10:52:00 AM1/25/02
to

e...@agharta.de (Dr. Edmund Weitz) writes:

..

> With most of the GNU stuff it's just './configure && make && make
> install' and it usually works.

With CL.CONFIGURATION is

(load "package.conf")
(conf:setup "PACKAGE")
(mk:compile-system "PACKAGE")
(mk:load-system "PACKAGE")

All in your favourite CL. No operating system dependencies (if there
are, they are bugs).

If you want to change some parameter you do

(conf:setup "PACKAGE" :source-location "/where/the/hell/is/the/code/")

(CL.CONFIGURATION has, untested, provisions to accomodate other
DEFSYSTEM utilities).

> But if it doesn't work, there's enough
> tutorial material out there to help you in understanding why it broke
> and how to fix it. I think we should work on providing the same level
> of documentation for CL.

On this I agree.

Ciao

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Thaddeus L Olczyk

unread,
Jan 25, 2002, 11:15:16 AM1/25/02
to
On 25 Jan 2002 09:25:03 -0500, Thom Goodsell
<tgoo...@DESPAM.cra.com> wrote:

>> I believe the lions share of jobs ( and I do believe getting a "lisp
>> job" is the goal of many of the newer people ) are in the "embedded
>> language" business where Lisp is used as an embedded scripting
>> language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
>> on ACL is the best thing.
>
>Can't agree with this one. If we try to cover every Lisp dialect and
>Lisp-like dialect this will end up being an unintelligible
>nightmare. As it is, much of the stuff in this cookbook will rely on
>something like CLOCC to cover implementation-dependent stuff. Trying
>to then include intirely new dialect is just way too much, IMHO.
>

I'm not saying that the solutions should be applicable to all
implementations.
What I am saying is that given one solution that works under many
different dialects ( I'll admit Scheme is a stretch. ) and another
that only works in ACL that the solution that works under many be
preffered.

Imagine for example that you have two solutions to a problem.
One relies on the "scoping scheme" of the dialect, and the other
does not. Choose the second. In fact try as much as possible to
write solutions of the second type.

Now there may be a solution that relies on scoping that is far
superior. That solution should be chosen.


>> Instead I think you should say that ACL solutions are prefered over
>> Scheme solutions or Emacs Lisp solutions. But in the end the best
>> solutions are ones that can be used by as many possible
>> implementations as is possible. ( You might hafve to tweak them
>> though. )
>
>The point is that one target audience of this book is people who
>wouldn't have the foggiest idea of what to tweak.
>

No the point is to teach the people "what to tweak".

Marco Antoniotti

unread,
Jan 25, 2002, 11:42:45 AM1/25/02
to

olc...@interaccess.com (Thaddeus L Olczyk) writes:

> On 25 Jan 2002 09:25:03 -0500, Thom Goodsell
> <tgoo...@DESPAM.cra.com> wrote:
>
> >> I believe the lions share of jobs ( and I do believe getting a "lisp
> >> job" is the goal of many of the newer people ) are in the "embedded
> >> language" business where Lisp is used as an embedded scripting
> >> language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
> >> on ACL is the best thing.
> >
> >Can't agree with this one. If we try to cover every Lisp dialect and
> >Lisp-like dialect this will end up being an unintelligible
> >nightmare. As it is, much of the stuff in this cookbook will rely on
> >something like CLOCC to cover implementation-dependent stuff. Trying
> >to then include intirely new dialect is just way too much, IMHO.
> >
> I'm not saying that the solutions should be applicable to all
> implementations.
> What I am saying is that given one solution that works under many
> different dialects ( I'll admit Scheme is a stretch. ) and another
> that only works in ACL that the solution that works under many be
> preffered.

Most little problems cannot be solved in Scheme, given the main design
goal of the language. Including the variants for the godzillion Scheme
implementations is not pragmatical.

As for ELisp, stick

(require 'cl)

in your .emacs (despite RMS' opinion) and you have solved the problem
of providing most of the portability.

Ciao

PS. Using the term ACL to refer to ANSI Common Lisp is confusing, as
ACL is usually used to refer to Allegro Common Lisp, the main
Franz Inc. product. Just saying CL implies the ANSI standard.

Erann Gat

unread,
Jan 25, 2002, 11:01:02 AM1/25/02
to

I used to believe this too until my recent foray into the real world. Not
only are transactions not the only thing that an SQL database buys you,
they aren't even the main thing. In fact, not all SQL databses even
support transactions.

The main thing an SQL database buys you (or any database for that matter)
is flexible, non-volatile indexing, making it easy e.g. to efficiently
find all the articles written by a particular person at a particular time
on a particular topic, even when the number of articles is very, very
large.

Erann

Marc Battyani

unread,
Jan 25, 2002, 12:40:20 PM1/25/02
to

"Erann Gat" <g...@jpl.nasa.gov> wrote

Sure but we were saying that the number of articles was very, very small ;-)

Marc


Tim Bradshaw

unread,
Jan 25, 2002, 1:11:04 PM1/25/02
to
* Erann Gat wrote:

> I used to believe this too until my recent foray into the real world. Not
> only are transactions not the only thing that an SQL database buys you,
> they aren't even the main thing. In fact, not all SQL databses even
> support transactions.

I think they are the main thing. My guess is that a lot more people
care a lot more about knowing that the system that handles all their
financial transactions works correctly than care about indexing. And
those people run investment banks and so on, so they have a lot of
money to spend on database systems.

Of course, indexing is an important thing but it definitely is not the
thing that pushes commercial database development. You have only to
look at the kind of benchmarks they compete on...

In fact, I'd always assumed that people who have really serious
indexing requirements use custom or semi-custom indexing systems.
Maybe not.

--tim

Erann Gat

unread,
Jan 25, 2002, 2:12:18 PM1/25/02
to
Tim Bradshaw <t...@cley.com> wrote:

> The only thing you get is transactions and that's hardly
> an issue here.

...


> I think they are the main thing. My guess is that a lot more people
> care a lot more about knowing that the system that handles all their
> financial transactions works correctly than care about indexing.

Maybe so, but we're not talking about a financial system here, we're
talking about a bulletin board. In that context transactions are neither
the main thing nor the only thing.

"Marc Battyani" <Marc.B...@fractalconcept.com> wrote:

> Sure but we were saying that the number of articles was very, very small ;-)

At the moment. Presumably the number of articles won't be small forever.

E.

Paolo Amoroso

unread,
Jan 25, 2002, 2:50:33 PM1/25/02
to
On 25 Jan 2002 14:20:54 +0100, e...@agharta.de (Dr. Edmund Weitz) wrote:

> Thanks. I think this is the way to go. What do you do if you can't
> reach the original author anymore?

I don't know, this has not happaned yet. If it does, I will probably not
include the material.

Dorai Sitaram

unread,
Jan 25, 2002, 3:11:41 PM1/25/02
to
In article <y6cu1ta...@octagon.mrl.nyu.edu>,

Cookbooks are appropriate for something that you have
to do everyday but are still in need of modest
variation (either to be useful or so you don't get
bored). Making everyday meals, everyday scripts...,
you get the picture. The Perl Cookbook is therefore
very apt. CL isn't used like that, so I don't see what
problem a Common Lisp cookbook can possibly solve.
Something to think about before committing
resources.

--d

Nils Goesche

unread,
Jan 25, 2002, 3:22:04 PM1/25/02
to
In article <a2se5t$l1c$1...@news.gte.com>, Dorai Sitaram wrote:

> Cookbooks are appropriate for something that you have to do everyday
> but are still in need of modest variation (either to be useful or so
> you don't get bored). Making everyday meals, everyday scripts..., you
> get the picture. The Perl Cookbook is therefore very apt. CL isn't
> used like that, so I don't see what problem a Common Lisp cookbook can
> possibly solve. Something to think about before committing resources.

The point was that it would be useful for beginners and for people
who haven't used CL for practical things yet. All existing books
address mainly advanced and/or theoretical issues. The great
``On Lisp'' teaches what you can do in CL what you can't do in other
languages; but there is no book I know of that teaches how you can do
in CL what you can do in other languages...

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x42B32FC9

Bijan Parsia

unread,
Jan 25, 2002, 6:01:53 PM1/25/02
to
On Thu, 24 Jan 2002, Thaddeus L Olczyk wrote:

[snip]


> While I hate to promote Smalltalk.

What? Instead of promoting *Perl*? ;)

Cheers,
Bijan Parsia.

Michael Naunton

unread,
Jan 25, 2002, 10:37:07 PM1/25/02
to
On 24 Jan 2002 10:52:13 +0100, Dr. Edmund Weitz <e...@agharta.de> wrote:

>- Basics: Installation, Loading and Compiling

>- Numbers: BIGNUMS, rationals, complex numbers

>- Strings / Regular Expressions
>- Dates and Times

>- Arrays
>- Hash Tables
>- Lists/Conses
>- Structures
>- CLOS

>- Other data structures: Btrees, Queues, Linked Lists

>- Iteration: LOOP, SERIES, MAP functions

>- Searching and Sorting


>- Input and Output, Streams, FORMAT, the Lisp Reader
>- Conditions, Error Handling

>- File Access, File Contents, Directories

>- Packages
>- Defsystem
>- Debugging, Profiling, Advice
>- Database Access
>- Sockets
>- Internet Protocols, Web Serving
>- Multi-Processing, Multi-Threading
>- FFI, Extending and Embedding CL
>- Communicating with other processes
>- GUI

>- I18N
>- XML
>- MOP

I think Sun got it right with their concept of "Trails" for Java. It's
hard to teach LISP in a linear fashion: if a user wants to know how to
read in a file, she's at chapter 15, and it makes no sense at all: e.g.
what's this "(foobar &list :opt fun-arg :rest a-list)" advice?

Trail 1 should be "Getting Started." That is installation and running
LISP. Final example is printing "hello world" and maybe (+ 2 2).
Compiling/profiling should be its own trail.

Don't try to explain Numbers: most people are happy that (/ 10 2) is 5.
Offer an advanced trail on using huge numbers and rationals.

The initial trails must solve common problems: how to read files,
ask the user for input, etc. Most users will give up if they can't
do the basics they need for their little test application.

I hate to say this, but the first data structures to be explained should
be the array and hash-table! Give the novices something they understand
and can build on. Introducing map and apply and lists on page 1 just
confuses the new user (consider a COBOL programmer learning PROLOG: yes,
it computes, but how can he use it?)

The trick is to introduce the powerful features of LISP (anonymous functions,
mapping, closures, macros, etc) in such a way that the expressiveness
offsets the perceived syntactic clunkiness. People don't want generality
when they are just trying to read a dictionary file... they just want the
file to get read!

Example: I wrote my first real LISP program in ten years last week: it
did the add-a-gram thingie: 60 lines total (C++ would have been 300+,)
and I spent almost all of my time trying to find trivial things: how to
read a file, convert a list to a sequence of chars, copy an array, etc.
The actual implementation of algorithm was trivial (maybe 10% of the total
time.)

Regards,
MMN

Thaddeus L Olczyk

unread,
Jan 25, 2002, 11:39:54 PM1/25/02
to

I do not promote the abomination called a language that was
written by Larry "Should Be Lined Up Against A" Wall.

synthespian

unread,
Jan 26, 2002, 12:50:56 AM1/26/02
to
In article <m3it9so...@bird.agharta.de>, e...@agharta.de (Dr. Edmund Weitz) wrote:
> I think most of you will agree that once you're hooked on Common Lisp
> you realize that you've found a language which has things to offer
> that no competitor has, so I won't discuss this any
> further. Nevertheless, CL is also a language that is somewhat hard for
> newcomers, especially for those who've used other, more widespread
> languages before: I come from the Perl/C/Java camp (and this is how I
> pay my rent) and there are myriads of _simple_ tasks that I could
> implement in these languages without thinking while I would have to
> work hard to get them done in CL. This is what this posting is about:
>
> I now that many c.l.l regulars despise Perl, but I hope you'll agree
> that the Perl community has a couple of things that we can learn
> from. The one thing that I'm going to talk about here is the famous
> (?) Perl Cookbook (see <http://www.oreilly.com/catalog/cookbook/>), a
> nice little book that provides concise, elegant and instructive
>

Hi -

I think yours is, in broad terms, a Good Idea. I mean, I'm a Lisp newbie, and
already I'm scared with this talk about how difficult it is to do trivial things...
Although I'm not able to contribute anything right now (except my opinion), I
feel I that I joint effort to index those issues in a web page would be far better
than having to buy yet another cookbook. Web sites are more dynamic, and don't cost
$50,00-plus dollars for you to update the information.
So, my vote goes for a web page (Cliki, maybe?).
I guess the bottom-line is that lispers have to make a coordinated effort to ease things
for the LIsp newbies.
These are all important questions which are bound to pop-up again and again unless
wide - preferably free - documentation is made avaliable.

Regs,

HL

Dr. Edmund Weitz

unread,
Jan 26, 2002, 2:21:00 AM1/26/02
to
synthespian <synth...@uol.com.br> writes:

> Although I'm not able to contribute anything right now (except
> my opinion), I feel I that I joint effort to index those issues in a
> web page would be far better than having to buy yet another
> cookbook. Web sites are more dynamic, and don't cost $50,00-plus
> dollars for you to update the information.

Yep. Maybe the term 'cookbook' is kinda misleading. I was talking
about making it available ob the Web all the time.

Edi.

Dr. Edmund Weitz

unread,
Jan 26, 2002, 2:23:12 AM1/26/02
to
olc...@interaccess.com (Thaddeus L Olczyk) writes:

> I do not promote the abomination called a language that was written
> by Larry "Should Be Lined Up Against A" Wall.

Wishing someone death just because he inventend a language that you
don't like? Hmmm - you're feeling better now?

Software Scavenger

unread,
Jan 26, 2002, 5:26:16 AM1/26/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) wrote in message news:<a2se5t$l1c$1...@news.gte.com>...

> Cookbooks are appropriate for something that you have
> to do everyday but are still in need of modest

I disagree. Cookbook recipes are more useful for things you do less
often, not things you do every day. If you do something every day,
you don't need a book to remind you how to do it. Cookbook recipes
are most useful the very first time you try something. For a
programming language, a cookbook is most useful the very first time
you try something in that language which you have done in other
languages.

Software Scavenger

unread,
Jan 26, 2002, 5:34:39 AM1/26/02
to
Yes, what a cookbook for novice users of Common Lisp should tell is
how to do something in Common Lisp which the user has done in other
languages. It should cover everything commonly done in other
languages, so no users will get stuck on such things, and they can
instead spend their time learning how to take full advantage of the
power of Common Lisp to do things that aren't done in other languages.

What the cookbook needs is a vast collection of example programs,
covering all the most common things done in other languages, and a
vast and powerful index, such that a programmer who knows how to do
something in a particular language can use that index to quickly find
out how to do the same thing in Common Lisp.

We don't have to explain each example program, as long as we clarify
what it does and what it's for. Having the example to play with is
enough for even the greenest novice to learn from.

A typical example program would compute the number of days between two
dates or the total number of bytes in all the files of a directory
tree. The index entries would have to be verbose to cover everything
anyone would use as search keys. For dates, the keywords would
include date, time, days, months, years, elapsed, duration, etc. The
index is as important as the content.

For this cookbook to be the best it can be, it has to be many
megabytes of useful information. The effort should be organized in
such a way that people can easily contribute large numbers of
miscellaneous example programs to it without making a mess of it and
without having to understand any complicated details of how to index
each entry. Maybe the entries should include a few extra lines of
comments containing index keywords, and other contributors could add
more index keywords to those. Maybe the actual indexing should just
use all the words found anywhere in the example. It might also be a
good idea for each entry to be reviewable by other contributors, who
can then add their comments to it, perhaps adding a better version of
the same program, etc.