From: William Y oung
Subject: Learning Lisp Paradigm/Conventions/Style?
Date: 
Message-ID: <3AFCBD05.D129C4DB@oakland.edu>
Hello all,
  I'm new to Lisp and this group, so please bear with me.

I'm just getting turned on to Lisp, and I'm really excited about using
it for a project (genetic programming aka GP).  Lisp is ideal, and is
probably _the_ preferred language for this work.  I tried implementing a
GP system in Matlab and got discouraged quickly.

So now I see the light and have acquired LispWorks.  Overall I'm very
impressed, but I seem to be lost in a new land.  I'm from mostly a
C/C++/VB background, and the Lisp environment operates differently from
what I'm accustomed to.  Hence, the following questions:

1)  The LispWorks documentation is pretty good, but it doesn't seem to
explain the overall Lisp environment.  I'm pretty lost just trying to
get a simple program running.  How are Lisp projects organized as sets
of files?  I'm looking for an analog to C's source and header files plus
make utility.  I have lots of references on the language itself but not
much to go on in terms of how to build a real live program.

2)  A search for Lisp books indicates that not many Lisp-based book have
been published in recent years.  The major references all seem ten years
old or more.  Is this because Lisp is a pretty mature language and it's
all been said already?  Or is the community really rather small?  Or is
there another primary source of information I'm not keyed in to?

3)  Where can I get an understanding of Lisp programming style?  My
"Lisp" book by Winston and Horn warns against trying to program C-style
in Lisp.  I want to avoid that.  I feel like I'm on the verge of a new
way of interepreting and solving problems, but haven't quite understood
yet.

Thanks in advance.  I'm very excited to learn what I can do with Lisp.

Bill Young
·······@oakland.edu

From: Friedrich Dominicus
Subject: Re: Learning Lisp Paradigm/Conventions/Style?
Date: 
Message-ID: <87lmo3nkht.fsf@frown.here>
William Y oung <·······@oakland.edu> writes:

> 
> 1)  The LispWorks documentation is pretty good, but it doesn't seem to
> explain the overall Lisp environment.  I'm pretty lost just trying to
> get a simple program running.  How are Lisp projects organized as sets
> of files?  I'm looking for an analog to C's source and header files plus
> make utility.  I have lots of references on the language itself but not
> much to go on in terms of how to build a real live program.

Do you really think you need it for getting started?
> 
> 2)  A search for Lisp books indicates that not many Lisp-based book have
> been published in recent years.  The major references all seem ten years
> old or more.
Now there are a few newer books. Maybe you should for Object Oriented
Common Lisp from Stephen Slade for learning and Norvigs book
"Paradigms of Artificial Intelligence Programming: Case Studies in
Common Lisp" which is certainly one of the best books I've read.



> Is this because Lisp is a pretty mature language and it's
> all been said already?
Some pointed out what the would like to see as a new book,e.g
documentation about CLOS. So there is still the need for more
documentation. The hard part is probably to convince O'Reilly,
Addison Wesley or or to publish such a book...



> Or is the community really rather small?
Do you think that is important?


>Or is
> there another primary source of information I'm not keyed in to?
HyperSpec (you'll got it with your LispWorks Distribution). Yes last
but not least this newsgroup is still active isn't it?

And Common Lisp the Language (online somewhere)

> 
> 3)  Where can I get an understanding of Lisp programming style?  My
> "Lisp" book by Winston and Horn warns against trying to program C-style
> in Lisp.  I want to avoid that.  I feel like I'm on the verge of a new
> way of interepreting and solving problems, but haven't quite understood
> yet.
Lisp is unique in it's combination of all sorts of programming. I do
think saying programming Lisp like C is to extreme. If the situation
is that doing it imperative seems to be right than it should be done
imperative..

You are probably facing some other problems. If you do not have done
some OO before CLOS may be difficult. If you do not have done
functional programming before you'll have hard time getting that.

My personal problem before starting was that I had no clue about
functional programming, bad luck. I helped myself with learning a
"pure" functional language (Haskell). And with that I got that kind of
programming. There is still one area where nothing helps but writing
Lisp the Makro System. I do not know any language with a simular
thing.

Stephen Slade states it very nicely (IMHO) in his book
"Many LISP programmers can be classified as true believers. For them,
LISP embodies computational truth, ligh and revelation" (page 6)

And
"Finally, it is most important that the reader of this book also write
programs. ... Only by writing programs will the reader attain
elightenment"



> 
> Thanks in advance.  I'm very excited to learn what I can do with
>Lisp.
It's undoubtful a good decision. I wished I had made it earlier (best
three years ago ;-)

Regards
Friedrich
From: mikel evins
Subject: Re: Learning Lisp Paradigm/Conventions/Style?
Date: 
Message-ID: <9dj0dk$585@dispatch.concentric.net>
"William Y oung" <·······@oakland.edu> wrote in message
······················@oakland.edu...

> I'm just getting turned on to Lisp, and I'm really excited about using
> it for a project (genetic programming aka GP

Good for you. I hope you enjoy it as much as I do.

> 1)  The LispWorks documentation is pretty good, but it doesn't seem to
> explain the overall Lisp environment.  I'm pretty lost just trying to
> get a simple program running.  How are Lisp projects organized as sets
> of files?

Pretty much any way you want. The basic model is different from a language
like C. In C you have a bunch of files that get built into an executable
that exists in the form of a slab of code (or a few slabs of code) that at
invocation get loaded into memory and started by jumping to main().

In Lisp instead there is a Lisp runtime world and you load blobs of code
into it until it knows how to do what you want. Then you call the code you
want to execute and it does its thing. You might build a distinct executable
by loading the code, changing the toplevel loop to be your code instead of
the Lisp's read-eval-print loop, and saving the heap image, either as an
image file or as a self-contained application, depending on your preferences
and the Lisp's capabilities. Or you might just compile it into files of
object code (Common Lisp compilers often name these '.fasl' files) and when
you want to use them load them into a running Lisp and call the functions
you want from the command line (the read-eval-print loop).

Either way, writing a Lisp program is not so much about source files and
object files and libraries and make and the linker and using them all to
build an executable. It's more about being in the Lisp runtime and modifying
it bit by bit by defining and redefining variables and functions and classes
until the Lisp runtime is your program. If writing a C program is about
nailing new pieces onto the standard library, writing a Lisp program is more
like teaching new skills to Lisp.

>  I'm looking for an analog to C's source and header files plus
> make utility.

Lisp source files are the source files (now that nobody uses structure
editors anymore!). Lisp source files are the header files. There is not
necessarily any difference, though you can create one if you want it, for
instance by putting all the stuff you mean to be public in one file and all
the stuff you mean to be private in another. (Of course you can't *really*
make anything private in Lisp except by compiling it without symbols and not
supplying the source, and even then it's not all the way private.)

>I have lots of references on the language itself but not
> much to go on in terms of how to build a real live program.

You just load definitions into the Lisp runtime until Lisp is your program.

> 2)  A search for Lisp books indicates that not many Lisp-based book have
> been published in recent years.  The major references all seem ten years
> old or more.  Is this because Lisp is a pretty mature language and it's
> all been said already?  Or is the community really rather small?  Or is
> there another primary source of information I'm not keyed in to?

I haven't noticed a lot of new ones either, but there are some great old
ones.

> 3)  Where can I get an understanding of Lisp programming style?

The best one I know of is _Structure and Interpretation of Computer
Programs_ by Abelson and Sussman. It uses Scheme, not Common Lisp, and it's
about Computer Science, not about Lisp style, but it uses Scheme programs to
illustrate all its points, it covers a great big chunk of what's interesting
in computer science, and it covers it by showing you how good Lisp hackers
think about it.

You obviously must have Steele's _Common Lisp the Language_ not only because
it's the classic reference but also because it's well written and
entertaining. Someone else recommended Norvig's _Paradigms of Artificial
Intelligence Programming_; that one is great. If you can find LISP Style and
Design by Molly Miller and Eric Benson, it covers one view of what Lisp
style ought to be like. The famous mathematician G. J. Chaitin gave a talk
on elegant Lisp programs that is transcribed at

http://www.cs.auckland.ac.nz/CDMTCS/chaitin/lisp.html

You might want to give that a read. It's not really about style; it's about
how a mathematician reasons about the kinds of things that you can say in
Lisp, but there's some relationship between the two, I think. :-)

Good luck and have fun. Lisp was maybe the fifth language I learned, which
was funny because it turned out to be my native language. I hope you have as
much fun as I have.
From: Kent M Pitman
Subject: Re: Learning Lisp Paradigm/Conventions/Style?
Date: 
Message-ID: <sfwk83mde52.fsf@world.std.com>
"mikel evins" <·······@mikelevins.com> writes:

> Pretty much any way you want. The basic model is different from a language
> like C. In C you have a bunch of files that get built into an executable
> that exists in the form of a slab of code (or a few slabs of code) that at
> invocation get loaded into memory and started by jumping to main().

Yes, other languages often focus on a function having the static name of 
"call me as toplevel" whereas in Lisp that's a role for a function to play;
the same function might be toplevel in one system and not in another.

> In Lisp instead there is a Lisp runtime world and you load blobs of code
> into it until it knows how to do what you want.  Then you call the code you
> want to execute and it does its thing. [...]

I agree with this.

> Either way, writing a Lisp program is not so much about source files and
> object files and libraries and make and the linker and using them all to
> build an executable.

Well, that's not the single-minded goal anyway.  But certainly source files
and compilation do happen--they are just detached from linking.  The purpose
of source file compilation is to deliver code to people who might want to 
load them.   Compiled files are an end-result deliverable in Lisp.  Other
Lisp programmers want to receive compiled files, not linked files.  Lispers
think of LOAD as a linking process, though it's logically distinct from the
linking process required to make an EXE.  So it's as if there are two kinds
of link--linking compiled lisp files into a lisp universe (through LOAD) and,
optionally, setting up a lisp universe to be a .exe (usualy done by a 
SAVE-IMAGE function).

> It's more about being in the Lisp runtime and modifying
> it bit by bit by defining and redefining variables and functions and classes
> until the Lisp runtime is your program.

Yes.  Maybe this is saying the same thing as I just said.

> If writing a C program is about nailing new pieces onto the standard
> library, writing a Lisp program is more like teaching new skills to
> Lisp.

Well, while I like the "teaching" metaphor, I'd say the way we write
"libraries" doesn't result in exec-level linkable libraries.  Rather,
it results in Lisp "packages", which have imports/exports that are not
externally visible.  Certainly we do package things...

> >  I'm looking for an analog to C's source and header files plus
> > make utility.
> 
> Lisp source files are the source files (now that nobody uses structure
> editors anymore!). Lisp source files are the header files.

On the Lisp Machine, files used to be organized into systems.  Many modern
systems have adopted this convention.  But one thing that was somewhat lost
along the way (though it's a convention I still use) is that every system
had a file called pkgdcl.lisp which declared the package.  It was usually
either the first or near-first loaded in the system definition, both so that
you could use the package in the rest of the definition and also so you could
just load the package definition without the rest of the system if you just
wanted to edit the code without loading it.  I think the pkgdcl.lisp file,
corresponded loosely to the .h file; or you could say defpackage does, and
that pkgdcl.lisp just gave it a file manifestation when really .h files map
to a form, not a file.

It is true that CL exports symbols, not definitions.  (Being a
multi-namespace language, this has different implications than for a
single-namespace language.)  It means that if you have a variable nad
a function with the same name, you can't export one without the other.
Although it's easy enough to shuffle the names, so this is never a
problem in practice.  But it does mean that loading only the package
definition is not enough for compiler diagnostics and editor hints
(control-shift-A in many editors to see a function's arglist while
editing a call to it) to know what the right parameter list is.
That's a weakness of the language, I suppose.  Though I suppose you
could make an augmented defpackage which did allow you to declare such
extra information and which just expanded into regular DEFPACKAGE plus
a set of stub function definitions.

> >I have lots of references on the language itself but not
> > much to go on in terms of how to build a real live program.
> 
> You just load definitions into the Lisp runtime until Lisp is your program.

And the cool thing about LOAD rather than other linkers is that the language
for expressing how to adjust the world into which you are linking is the same
as the language for writing programs.  So instead of some goopy syntax for
#IFNDEF or whatever special-purpose bizarreneses is introduced into other
languages to handle the myriad special-cases of things being either present
or not present, you just do things like:


(defun foo (x) (bar x))

(unless (fboundp 'bar) ;if the definition of bar isn't present here
  (load "bar-support"))

If you need the code also at compile time, not just load time (e.g., because
it has a macro definition in it), you need:

(eval-when (:compile-toplevel :execute)
  (unless (fboundp 'bar) ;if the definition of bar isn't present here
    (load "bar-support")))

EVAL-WHEN helps you control evaluation time for things that need to happen
at one or more specific times.

> > 2)  A search for Lisp books indicates that not many Lisp-based book have
> > been published in recent years.  The major references all seem ten years
> > old or more.  Is this because Lisp is a pretty mature language and it's
> > all been said already?  Or is the community really rather small?  Or is
> > there another primary source of information I'm not keyed in to?
> 
> I haven't noticed a lot of new ones either, but there are some great old
> ones.

I think there is some book on Lisp Machine culture that might have had
some of this in it.  Certainly the Lisp Machine docset had a lot about
such.  But it was very large.  For those who don't know what a Lisp
Machine is, think of it as the logical analog of the Aztecs or the
Incas to any modern day moderness.  They're still available but rare.
The only really active line of them is emulated on the ALPHA.  But in
their day, they covered the earth like buffalo and were at the top of
their food chain, not, as now, relegated to zoos.  

> 3)  Where can I get an understanding of Lisp programming style?
> 
> The best one I know of is _Structure and Interpretation of Computer
> Programs_ by Abelson and Sussman. It uses Scheme, not Common Lisp, and it's
> about Computer Science, not about Lisp style, but it uses Scheme programs to
> illustrate all its points, it covers a great big chunk of what's interesting
> in computer science, and it covers it by showing you how good Lisp hackers
> think about it.

I really personally don't think S&ICP is a good choice of book for
teaching anything to do with Lisp style.  Most people agree it teaches
some very interesting concepts, but the programming style it promotes
is not suitable for Lisp without a lot of modification.  I guess I'd
say it's about styles of thinking, but its worth is at a different level
than the style of program organization, especially file/syntax organization.

Get some of Peter Norvig's books.  Also if you do a web search, you'll find
his notes on style from a seminar on style that he and I gave together at LUV
some years back.

> You obviously must have Steele's _Common Lisp the Language_ not only because
> it's the classic reference but also because it's well written and
> entertaining. Someone else recommended Norvig's _Paradigms of Artificial
> Intelligence Programming_; that one is great. If you can find LISP Style and
> Design by Molly Miller and Eric Benson, it covers one view of what Lisp
> style ought to be like. The famous mathematician G. J. Chaitin gave a talk
> on elegant Lisp programs that is transcribed at
> 
> http://www.cs.auckland.ac.nz/CDMTCS/chaitin/lisp.html
> 
> You might want to give that a read. It's not really about style; it's about
> how a mathematician reasons about the kinds of things that you can say in
> Lisp, but there's some relationship between the two, I think. :-)
> 
> Good luck and have fun. Lisp was maybe the fifth language I learned, which
> was funny because it turned out to be my native language. I hope you have as
> much fun as I have.

Me too.

Please don't take my comments here as negating what mikel has said; I just
wanted to add some counterpoint to add some breadth.
From: Marco Antoniotti
Subject: Re: Learning Lisp Paradigm/Conventions/Style?
Date: 
Message-ID: <y6ck83ms6d9.fsf@octagon.mrl.nyu.edu>
Kent M Pitman <······@world.std.com> writes:

> On the Lisp Machine, files used to be organized into systems.  Many modern
> systems have adopted this convention.  But one thing that was somewhat lost
> along the way (though it's a convention I still use) is that every system
> had a file called pkgdcl.lisp which declared the package.  It was usually
> either the first or near-first loaded in the system definition, both so that
> you could use the package in the rest of the definition and also so you could
> just load the package definition without the rest of the system if you just
> wanted to edit the code without loading it.  I think the pkgdcl.lisp file,
> corresponded loosely to the .h file; or you could say defpackage does, and
> that pkgdcl.lisp just gave it a file manifestation when really .h files map
> to a form, not a file.

That is the way I write my code.  I usually have a .system file which
contains

	(defsystem "THE-SYSTEM"
            :components ("the-system-package"
                         (:file "some-file"
                                :depends-on ("the-system-package"))
                         ...))


> It is true that CL exports symbols, not definitions.  (Being a
> multi-namespace language, this has different implications than for a
> single-namespace language.)  It means that if you have a variable nad
> a function with the same name, you can't export one without the other.
> Although it's easy enough to shuffle the names, so this is never a
> problem in practice.  But it does mean that loading only the package
> definition is not enough for compiler diagnostics and editor hints
> (control-shift-A in many editors to see a function's arglist while
> editing a call to it) to know what the right parameter list is.
> That's a weakness of the language, I suppose.  Though I suppose you
> could make an augmented defpackage which did allow you to declare such
> extra information and which just expanded into regular DEFPACKAGE plus
> a set of stub function definitions.

I remember making such a suggetion a long time ago.

	(defpackage* "THE-PACKAGE"
           (:export ("F" :ftype (function (fixnum string) character))
                    ("X" :type X)
                    ("TT" :defined-type t)))

Of course you run into problems when you want to define things like

	(defpackage* "THE-PACKAGE"
           (:export ("F1" :ftype (function (fixnum string) tt))
                    ("X" :type X)
                    ("TT" :defined-type t)))

I.e. which 'TT' are you referring to?


> I think there is some book on Lisp Machine culture that might have had
> some of this in it.  Certainly the Lisp Machine docset had a lot about
> such.  But it was very large.  For those who don't know what a Lisp
> Machine is, think of it as the logical analog of the Aztecs or the
> Incas to any modern day moderness.  They're still available but rare.
> The only really active line of them is emulated on the ALPHA.  But in
> their day, they covered the earth like buffalo and were at the top of
> their food chain, not, as now, relegated to zoos.

Maybe that's too bad.  But given how costly they were, they are a
monument to management short-sightness.

Cheers

-- 
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'.
From: Christopher Stacy
Subject: Re: Learning Lisp Paradigm/Conventions/Style?
Date: 
Message-ID: <uelttsv4b.fsf@spacy.Boston.MA.US>
>>>>> On 12 May 2001 15:40:50 -0400, Marco Antoniotti ("Marco") writes:
 Marco> Maybe that's too bad.  But given how costly they were, they are a
 Marco> monument to management short-sightness.

I'm not sure at exactly what point I'd draw the line, but for a quite
while from the beginning, they were competitively priced.  The cost per
se is not really what sank things, as much as a lack of understanding of
how to help customers succeed with the unique capabilities that the
system offered.  (That is, the company was not market-oriented.)
From: John Flynn
Subject: Re: Learning Lisp Paradigm/Conventions/Style?
Date: 
Message-ID: <1y3L6.4604$ZJ.173190@ozemail.com.au>
"William Y oung" <·······@oakland.edu> wrote in message
······················@oakland.edu...

> I'm just getting turned on to Lisp, [...]

Me too. Fascinating stuff.

[...]

> 1)  The LispWorks documentation is pretty good, but it doesn't seem to
> explain the overall Lisp environment.  I'm pretty lost just trying to
> get a simple program running.  How are Lisp projects organized as sets
> of files?  I'm looking for an analog to C's source and header files plus
> make utility.  I have lots of references on the language itself but not
> much to go on in terms of how to build a real live program.

For a quick intro:
Help->Manuals->LispWorks User Guide
See Section 12: Common Defsystem.
It's serves the same purpose as "make".

> [...] I feel like I'm on the verge of a new
> way of interepreting and solving problems, but haven't quite understood
> yet.

Know that feeling ;-)