········@this.place wrote:
> Are there any Lisp books in the style
> of "The C Programming Language" by K&R?
>
Maybe Paul Graham's "ANSI Common Lisp"?
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
········@this.place wrote:
> Are there any Lisp books in the style
> of "The C Programming Language" by K&R?
If Scheme counts as a Lisp, then "The Scheme Programming
Language" by Dybvig fits the bill.
<http://www.scheme.com/tspl3/>
--
Jens Axel Søgaard
There canot be a K&R like book for Lisp because its a different kind of
language. You see, if you know the rules for tic-tac-toe you know to
play tic-tac-toe but if you know the rules of chess you dont know
chess. Its like that.
I think these 4 books together make good combo,
1)Common Lisp: An Interactive Aproach
2)On Lisp
3)Commmon Lisp The Language
4)Practical Common Lisp
Lisp supports 5 styles of programming
1>Functional
2>Applicative
3>Imperative
4>Object Oriented
Book (1) introduces you to all of them.
Book (2) shapens your lisp skills.
Book (3) tells you a lot about lisp, must read or you will end up
duplicating the functionality already present in lisp.
Book (4) is to learn to work on real world apps.
All these books are free!!!!
Hope this helps,
Nikhil Ketkar
On 1 May 2005 23:01:26 -0700, "Nikhil Ketkar" <············@gmail.com> wrote:
> I think these 4 books together make good combo,
> 1)Common Lisp: An Interactive Aproach
> 2)On Lisp
> 3)Commmon Lisp The Language
> 4)Practical Common Lisp
>
> Lisp supports 5 styles of programming
> 1>Functional
> 2>Applicative
> 3>Imperative
> 4>Object Oriented
Five? Hmmm...
Anyway, to me this sounds as if all of these styles were mutually
exclusive. That's not necessarily the case. The beauty of Lisp is
that you can mix them as you like it.
> Book (1) introduces you to all of them.
> Book (2) shapens your lisp skills.
> Book (3) tells you a lot about lisp, must read or you will end up
> duplicating the functionality already present in lisp.
> Book (4) is to learn to work on real world apps.
I think (4) is a very good book to start learning Lisp, escpecially if
you already know other programming languages like Java or C. (2) is a
great book but it is quite advanced and assumes that you've already
mastered the basics. (3) describes a point in time during the
standardization process but not the language as defined by ANSI now.
For that you should look at the ANSI standard which is available
in HTML-ized form here:
<http://www.lispworks.com/documentation/HyperSpec/Front/index.htm>
(3) includes some stuff that is of historical interest and it also
includes more explanation than the ANSI standard. But if in doubt you
have to check the standard. (1) I don't know good enough.
For learning good, idiomatic Lisp I'd also recommend Peter Norvig's
PAIP:
<http://www.norvig.com/paip.html>
> All these books are free!!!!
What does "free" mean? All these books are available for online
reading but still copyrighted works. Some of them are also available
in dead-tree form so if you like them you should consider buying them
to support their authors.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> What does "free" mean? All these books are available for online
> reading but still copyrighted works. Some of them are also available
> in dead-tree form so if you like them you should consider buying them
> to support their authors.
And the publishers who invest in Lisp.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Nikhil Ketkar wrote:
> There canot be a K&R like book for Lisp because its a different kind of
> language.
No doubt, but I assume the OP knew that. So we are looking for other
commonalities:
- high quality prose
- exercises at the end of the chapters
- usable as a reference as well as a linear course of study
But I did not actually drag out K&R and Paul's book, so maybe I am
missing something else.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> Nikhil Ketkar wrote:
>
>> There canot be a K&R like book for Lisp because its a different kind of
>> language.
>
> No doubt, but I assume the OP knew that. So we are looking for other
> commonalities:
>
> - high quality prose
> - exercises at the end of the chapters
> - usable as a reference as well as a linear course of study
- concise
- written by people intimately familiar with the language
--
Gareth McCaughan
.sig under construc
Kenny Tilton <·······@nyc.rr.com> writes:
> Nikhil Ketkar wrote:
>
>> There canot be a K&R like book for Lisp because its a different kind of
>> language.
>
> No doubt, but I assume the OP knew that. So we are looking for other
> commonalities:
>
> - high quality prose
> - exercises at the end of the chapters
> - usable as a reference as well as a linear course of study
>
> But I did not actually drag out K&R and Paul's book, so maybe I am
> missing something else.
>
I think one of the key things about K&R's book was that it was
increadibly concise, small clear and contained good examples
etc. Putting aside language issues for a moment, I would have to say
that learning C with that book was one of the more pleasant
experiences I had when tackling a new language.
Unfortunately, the trend with computer books these days seems to be to
see how many dead trees you can squeeze into one book. It never ceases
to amaze me how books with so many pages contain such little
substance.
Personally, I'd love a K&R style book for CL, but I'm not sure it can
be done. The hyperspec is great, but sometimes you want just a little
more context and you want a book where you can find the paragraph
relevant to what you are doing quickly and find that when you have
read it, you have more understanding. I've found with many Lisp books
that while I might eventually find an answer to my question, I end up
with more questions. However, this is more likely to be a function of
the language than how the authors have written the book.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Tim X <····@spamto.devnul.com> writes:
> Personally, I'd love a K&R style book for CL, but I'm not sure it can
> be done. The hyperspec is great, but sometimes you want just a little
> more context and you want a book where you can find the paragraph
> relevant to what you are doing quickly and find that when you have
> read it, you have more understanding. I've found with many Lisp books
> that while I might eventually find an answer to my question, I end up
> with more questions. However, this is more likely to be a function of
> the language than how the authors have written the book.
Keene's book on CLOS has an appealing thinness to it.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
Nikhil Ketkar wrote:
> Lisp supports four styles of programming
> 1>Functional
> 2>Applicative
> 3>Imperative
> 4>Object Oriented
One question: in what language can you /not/ programm object oriented?
Andr�
--
Andr� Thieme schrieb:
> Nikhil Ketkar wrote:
>
>> Lisp supports four styles of programming
>> 1>Functional
>> 2>Applicative
>> 3>Imperative
>> 4>Object Oriented
>
>
> One question: in what language can you /not/ programm object oriented?
You can program any way you like in any turing-complete language by
implementing half of common lisp in it.
Language support makes it far easier though.
AFAIK language support for OO-style programming is missing in Awk, C,
Forth, Fortran, APL, Prolog.
Patrick Frankenberger wrote:
<snip>
> > One question: in what language can you /not/ programm object
oriented?
>
> You can program any way you like in any turing-complete language by
> implementing half of common lisp in it.
>
> Language support makes it far easier though.
>
> AFAIK language support for OO-style programming is missing in Awk, C,
> Forth, Fortran, APL, Prolog.
Fortran 90 has user-defined types with public and private members and
operator overloading and thus provides some support for OOP. Fortran
2003 adds single inheritance and other OOP features.
·········@aol.com wrote:
> Patrick Frankenberger wrote:
>
> <snip>
>
>>>One question: in what language can you /not/ programm object
>
> oriented?
>
>>You can program any way you like in any turing-complete language by
>>implementing half of common lisp in it.
>>
>>Language support makes it far easier though.
>>
>>AFAIK language support for OO-style programming is missing in Awk, C,
>
>
>>Forth, Fortran, APL, Prolog.
>
>
> Fortran 90 has user-defined types with public and private members and
> operator overloading and thus provides some support for OOP. Fortran
> 2003 adds single inheritance and other OOP features.
Have they added recursive functions?
Cheers
--
Marco
Hello!
Marco Antoniotti <·······@cs.nyu.edu> wrote:
>> Fortran 90 has user-defined types with public and private members and
>> operator overloading and thus provides some support for OOP. Fortran
>> 2003 adds single inheritance and other OOP features.
>Have they added recursive functions?
Yes. IIRC since F'90.
Kind regards,
Hannah.
Hannah Schroeter wrote:
> Hello!
>
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>
>>>Fortran 90 has user-defined types with public and private members and
>>>operator overloading and thus provides some support for OOP. Fortran
>>>2003 adds single inheritance and other OOP features.
>
>
>>Have they added recursive functions?
>
>
> Yes. IIRC since F'90.
>
Ok. So the only real advantage that Fortran had over C when writing
numerical software is essentially gone.
I feel I can safely say that right now people are writing Fortran code
because it is a bitch to interface 1-based column-major matrix code with
0 based row-major languages :)
Don't ask me to back it up. It is a conjecture. :)
Cheers
--
Marco
Marco Antoniotti wrote:
> >>[Has Fortran] added recursive functions?
> >
> >
> > Yes. IIRC since F'90.
> >
>
> Ok. So the only real advantage that Fortran had over C when writing
> numerical software is essentially gone.
> I feel I can safely say that right now people are writing Fortran
code
> because it is a bitch to interface 1-based column-major matrix code
with
> 0 based row-major languages :)
I don't understand why adding recursive functions to Fortran makes it a
poorer language for numerical software. If you are saying there is a
speed penalty for using recursion, the programmer can avoid using it in
the time-critical sections of the code. He need not declare every
function "recursive".
Fortran 90/95 has operations on arrays and array sections, which make
many codes using arrays much smaller than their Fortran 77 or C
analogs.
·········@aol.com wrote:
> Marco Antoniotti wrote:
>
>
>>>>[Has Fortran] added recursive functions?
>>>
>>>
>>>Yes. IIRC since F'90.
>>>
>>
>>Ok. So the only real advantage that Fortran had over C when writing
>>numerical software is essentially gone.
>>I feel I can safely say that right now people are writing Fortran
>
> code
>
>>because it is a bitch to interface 1-based column-major matrix code
>
> with
>
>>0 based row-major languages :)
>
>
> I don't understand why adding recursive functions to Fortran makes it a
> poorer language for numerical software. If you are saying there is a
> speed penalty for using recursion, the programmer can avoid using it in
> the time-critical sections of the code. He need not declare every
> function "recursive".
Sorry. That was not my intention. I am simply stating a fact. AFAIK,
in Fortran77 and ancestors, subroutines "statically" laid out and
calling from one to another did not incur the cost of pushing a stack
frame. By adopting recursion, F90/95 cannon claim this "efficiency
advantage" anymore.
> Fortran 90/95 has operations on arrays and array sections, which make
> many codes using arrays much smaller than their Fortran 77 or C
> analogs.
That is good. So does Ada. Basically what you are saying is that the
key to writing numerical software now resides on the basic array
manipulation facilities that the language has to offer. I can live with
that.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> By adopting recursion, F90/95 cannon claim this "efficiency
> advantage" anymore.
Since they also have nonrecursive functions, they can still claim it.
Also, Fortran doesn't have the aliasing problems that C has blocking
optimization.
> That is good. So does Ada. Basically what you are saying is that the
> key to writing numerical software now resides on the basic array
> manipulation facilities that the language has to offer. I can live with
> that.
Yep, for many scientific codes, that's complete, because the better
the basic array manipulations, the more easy you can run it on massive
clusters.
--
Alan Shutko <···@acm.org> - I am the rocks.
Marco Antoniotti wrote:
> ...
> Sorry. That was not my intention. I am simply stating a fact. AFAIK,
> in Fortran77 and ancestors, subroutines "statically" laid out and
> calling from one to another did not incur the cost of pushing a stack
> frame.
for most algol derived languages this is a very cheap operation, whose
cost is often offset by more efficient code for the local variables
(which often can be kept in registers)
> By adopting recursion, F90/95 cannon claim this "efficiency
> advantage" anymore.
so this isn't really an advantage. it was different on some of the
older mainframe architectures
> ...
hs
Hartmann Schaffer wrote:
> Marco Antoniotti wrote:
>
>> ...
>> Sorry. That was not my intention. I am simply stating a fact.
>> AFAIK, in Fortran77 and ancestors, subroutines "statically" laid out
>> and calling from one to another did not incur the cost of pushing a
>> stack frame.
>
>
> for most algol derived languages this is a very cheap operation, whose
> cost is often offset by more efficient code for the local variables
> (which often can be kept in registers)
>
>> By adopting recursion, F90/95 cannon claim this "efficiency
>> advantage" anymore.
>
>
> so this isn't really an advantage. it was different on some of the
> older mainframe architectures
>
Point taken. But I bet that some Fortran advocates may have a different
point of view. :)
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> wrote:
> By adopting recursion, F90/95 cannon claim this "efficiency
> advantage" anymore.
You didn't understand. In F90, you still have to separately mark a
function as RECURSIVE when you intend to use it recursively. If you don't
mark (some of) your functions recursive, then I guess there is nothing to
stop the compiler making the old kind of optimizations.
Sampo Smolander wrote:
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>>By adopting recursion, F90/95 cannon claim this "efficiency
>>advantage" anymore.
>
>
> You didn't understand. In F90, you still have to separately mark a
> function as RECURSIVE when you intend to use it recursively. If you don't
> mark (some of) your functions recursive, then I guess there is nothing to
> stop the compiler making the old kind of optimizations.
Ok. Got it. I never claimed deep expertise in F90.
From this discussion I gather that what F90 is bringing to the table is
a nice set of array manipulation facilities, which do make numerical
computing easier.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> wrote:
> Have they added recursive functions?
They were in Fortran 90, though you have to mark them like:
RECURSIVE FUNCTION f(x,y)
...
Probably also a lot earlier as almost-standard-non-standard
extensions in several f77 compilers.
On 3 May 2005 14:09:36 -0700, <············@gmail.com> wrote:
>
> You can do anything in any language.
As a long time perl coder, I never learned how to update running
source, something I did this morning in cmucl at about 3x the
development rate of the old run-check output-recode-do over method.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Maks Romih
Subject: Changing source on the fly (Was: Lisp Book(s) in the K&R Style)
Date:
Message-ID: <u3bt0968j.fsf_-_@snt.si>
Is it possible in CMUCL to change the source when stepping through the
debugger? I mean, the source of the very function or loop you are
stepping through.
This is one of few things that I've enjoyed in Visual Basic and I'm
curious when I will find it in any lisp debugger.
GP lisper <········@CloudDancer.com> writes:
> On 3 May 2005 14:09:36 -0700, <············@gmail.com> wrote:
> >
> > You can do anything in any language.
>
> As a long time perl coder, I never learned how to update running
> source, something I did this morning in cmucl at about 3x the
> development rate of the old run-check output-recode-do over method.
>
>
> --
> Everyman has three hearts;
> one to show the world, one to show friends, and one only he knows.
In article <················@snt.si>, Maks Romih <·····@snt.si> wrote:
> Is it possible in CMUCL to change the source when stepping through the
> debugger? I mean, the source of the very function or loop you are
> stepping through.
I expect that you can redefine the function, but it won't affect the
current execution that's in progress. Unless the function is
inline-coded into the callers, it should affect subsequent calls to the
function.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Maks Romih
Subject: Re: Changing source on the fly
Date:
Message-ID: <uvf5uq6kx.fsf_-_@snt.si>
GP lisper <········@CloudDancer.com> says that he "updates running
source...in cmucl", so I just wanted to know a bit more, how he does
it. It seems he didn't see my late follow-up.
I'm comparing Visual Basic to Lisp and I want to see, how everything
that can be done in Visual Basic, can be done in Lisp, concretely in
the cmucl+slime environment.
Until now I've not found out, how I can elegantly play with the
s-expressions in some source buffer that I evalute in the context of a
breakpoint in slime+cmucl debugger. The most I've found out is
evaluating expressions with e in sldb prompt, but I have to enter the
expression. I would like to just show it in the source buffer, like
the C-x e command. I will actually try to adapt C-x e command to
evalute in debug context.
Maks Romih.
Barry Margolin <······@alum.mit.edu> writes:
> In article <················@snt.si>, Maks Romih <·····@snt.si> wrote:
>
> > Is it possible in CMUCL to change the source when stepping through the
> > debugger? I mean, the source of the very function or loop you are
> > stepping through.
>
> I expect that you can redefine the function, but it won't affect the
> current execution that's in progress. Unless the function is
> inline-coded into the callers, it should affect subsequent calls to the
> function.
>
> --
> Barry Margolin, ······@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
On 08 May 2005 13:51:10 +0200, <·····@snt.si> wrote:
> GP lisper <········@CloudDancer.com> says that he "updates running
> source...in cmucl", so I just wanted to know a bit more, how he does
> it. It seems he didn't see my late follow-up.
I did see it, but Barry answered it.
> I'm comparing Visual Basic to Lisp and I want to see, how everything
> that can be done in Visual Basic, can be done in Lisp, concretely in
> the cmucl+slime environment.
>
> Until now I've not found out, how I can elegantly play with the
> s-expressions in some source buffer that I evalute in the context of a
> breakpoint in slime+cmucl debugger. The most I've found out is
> evaluating expressions with e in sldb prompt, but I have to enter the
> expression. I would like to just show it in the source buffer, like
> the C-x e command. I will actually try to adapt C-x e command to
> evalute in debug context.
Barry already answered this query. I don't use the debugger, "print"
statement debugging is much faster and rarely leads you down the wrong
path due to cascading errors. If you enjoy Visual Basic a lot, you
should probably not use CMUCL, but try Allegro instead, as some claim
it to be very much like VB.
Updating running source is simply done with two REPLs. CMUCL will
give you a second REPL via telnet for:
(setf mp::*idle-process* mp::*initial-process*)
(mp::start-lisp-connection-listener :port 6789 :password "fred")
NOTE: include the quotes for the password string in your telnet
In the mentioned case, one REPL on a remote computer was parsing a 6.5
hour long datastream, the second REPL received updated source via X
'cut-n-paste', after some quick testing (or not ;-) in a local slime.
Note that you can always test any part of Lisp at any time, if you
have followed the guidelines that Paul Graham lays down for such an
ability...i.e. definately worth doing! Thus some of the reasons you
might employ a debugger no longer exist.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
> Updating running source is simply done with two REPLs. CMUCL will
> give you a second REPL via telnet for:
>
> (setf mp::*idle-process* mp::*initial-process*)
> (mp::start-lisp-connection-listener :port 6789 :password "fred")
>
> NOTE: include the quotes for the password string in your telnet
I got the second REPL to come up, but the first never returned from
setting the listener. What did I miss? I thought after starting the
listener, I could then load my source and run it, while modifying it in
the _other_ REPL.
On 11 May 2005 07:12:44 -0700, <···········@bigfoot.com> wrote:
>> Updating running source is simply done with two REPLs. CMUCL will
>> give you a second REPL via telnet for:
>>
>> (setf mp::*idle-process* mp::*initial-process*)
>> (mp::start-lisp-connection-listener :port 6789 :password "fred")
>>
>> NOTE: include the quotes for the password string in your telnet
>
> I got the second REPL to come up, but the first never returned from
> setting the listener. What did I miss? I thought after starting the
> listener, I could then load my source and run it, while modifying it in
> the _other_ REPL.
hehe, I'll bet that your REPL is patiently sitting there, waiting for
you to type something. Try a simple (+ 3 4 5) at the line under the
prompt.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
GP lisper wrote:
> > I got the second REPL to come up, but the first never returned from
> > setting the listener. What did I miss? I thought after starting
the
> > listener, I could then load my source and run it, while modifying
it in
> > the _other_ REPL.
>
> hehe, I'll bet that your REPL is patiently sitting there, waiting for
> you to type something. Try a simple (+ 3 4 5) at the line under the
> prompt.
Silly me. You were right.
So I go ahead and start the program, right? Is there any way to
display source in the REPL or can I only enter modified code to replace
functions?
Jonathon
On 12 May 2005 04:58:08 -0700, <···········@bigfoot.com> wrote:
> GP lisper wrote:
>> > I got the second REPL to come up, but the first never returned from
>> > setting the listener. What did I miss? I thought after starting
>> > the listener, I could then load my source and run it, while modifying
>> > it in the _other_ REPL.
>>
>> hehe, I'll bet that your REPL is patiently sitting there, waiting for
>> you to type something. Try a simple (+ 3 4 5) at the line under the
>> prompt.
>
> Silly me. You were right.
The mp startup emits something, most likely a newline at the end of
some code portion and the REPL behaves just as if you had typed an
extra newline.
> So I go ahead and start the program, right? Is there any way to
> display source in the REPL or can I only enter modified code to replace
> functions?
Well, I would suggest that you simply try out your ideas rather than
waiting for someone to read your question and reply via usenet. You
should find that the waiting time is significantly reduced, and your
confidence enhanced.
When I was exclusively using the REPL, I never learned how to display
source for anything I had previously typed, but I'm sure there must be
some way (other than the rlwrap I was using). Since I am permanently
SLIME addicted nowdays, seeing the source, checking the hyperspec,
finding the callers, etc. are simple abilities. Get Slimed!
As to the second REPL, it is the same as any other REPL except for
some error handling (which may appear in the first REPL). You can
examine any part of the running code, toggle variables, etc. Keep in
mind that threads in CMUCL are the 'friendly' type, similar to the
multitasking in old Mac System 6 or early Windoze. With the Slime
support I had locally, the only ability I needed was replacing source
code and checking some state variables. Sometimes, you might need to
issue a file recompile in the second REPL in order to get your changes
into place, or just compile your last change -- this is probably
related to the 'green threads' nature of CMUCL. SBCL is not really
better, since large portions of it's source code are still from CMUCL
[or maybe the documentation for SBCL is totally out-of-date on this
matter] and suffer from the same limitations.
The source code I was working on had two functions to start off, one
for a file-reading stream task and the other for a real-time stream
reading task. The file was simply a capture of an eariler real-time
stream. Naturally, both functions simply setup the streams, and then
called the remaining functions. So a local slime could read a file
for test input, and I would know that the remote REPL wouldn't crash
due to some silly error before I replaced the source.
I think I've covered everything now....
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
GP lisper wrote:
> Well, I would suggest that you simply try out your ideas rather than
> waiting for someone to read your question and reply via usenet. You
> should find that the waiting time is significantly reduced, and your
> confidence enhanced.
I am following the directions in PCL, and made a package to play in
with AllegroServe. Now I can't (quit) :-\
I tried (in-package :cl) then (quit) but I keep getting errors that the
function is not found. I guess I need to learn how the REPL can show
availabe functions and so on.
> When I was exclusively using the REPL, I never learned how to display
> source for anything I had previously typed, but I'm sure there must
be
> some way (other than the rlwrap I was using). Since I am permanently
> SLIME addicted nowdays, seeing the source, checking the hyperspec,
> finding the callers, etc. are simple abilities. Get Slimed!
I *just* convinced myself to go back to VIM from Xemacs. Ugh.
jonathon wrote:
> I am following the directions in PCL, and made a package to play in
> with AllegroServe. Now I can't (quit) :-\
>
> I tried (in-package :cl) then (quit) but I keep getting errors that the
> function is not found. I guess I need to learn how the REPL can show
> availabe functions and so on.
It's probably not in COMMON-LISP, but some other
(implementation-specific) package.
Just read that last night:
PCL Ch. 21 footnote 3 (p.267) tells you how to find out what other
packages you have in CL-USER.
Or you just IN-PACKAGE to :cl-user and then (QUIT) or (EXIT).
--
Don't let school interfere with your education. -- Mark Twain
In article <························@g43g2000cwa.googlegroups.com>,
jonathon wrote:
> GP lisper wrote:
>> Since I am permanently SLIME addicted nowdays, seeing the source,
>> checking the hyperspec, finding the callers, etc. are simple
>> abilities. Get Slimed!
>
> I *just* convinced myself to go back to VIM from Xemacs. Ugh.
VILisp[1] may help. VILisp is highly inferior to SLIME, and basically
only automates cut-and-paste between Vim and Lisp, but it's reasonably
handy. See also here[2].
I hope to have a few hours on an upcoming plane trip to cook up some
rudimentary SWANK support for Vim. (SWANK is the backend for SLIME.)
-- Larry
[1] http://vim.sourceforge.net/scripts/script.php?script_id=221
[2] http://vim.sourceforge.net/scripts/script.php?script_id=165
Larry Clapp wrote:
> VILisp[1] may help. VILisp is highly inferior to SLIME, and
basically
> only automates cut-and-paste between Vim and Lisp, but it's
reasonably
> handy. See also here[2].
>
> I hope to have a few hours on an upcoming plane trip to cook up some
> rudimentary SWANK support for Vim. (SWANK is the backend for SLIME.)
I actually did run across your name and project recently. Please keep
me posted on your SWANK support progress. I'd be very interested.
Jonathon
GP lisper <········@clouddancer.com> wrote:
+---------------
| When I was exclusively using the REPL, I never learned how to display
| source for anything I had previously typed, but I'm sure there must be
| some way (other than the rlwrap I was using). ...
+---------------
Well, it's *horribly* limited and the formatting is probably lousy
[depending on your implementation], but have you tried the standard
variables "+", "++", & "+++"? They've occasionally saved my bacon
when I was typing at the REPL and didn't have access to cut & paste... ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"jonathon" <···········@bigfoot.com> writes:
> So I go ahead and start the program, right? Is there any way to
> display source in the REPL or can I only enter modified code to replace
> functions?
Well, you could use (fdefinition 'myfun)
or (function-lambda-expression (symbol-function 'myfun))
but the implementations are not mandated to return anything helpful,
so if you want to "edit the source" in the REPL, you should start with:
(defpackage "MY-COMMON-LISP"
(:nicknames "MY-CL")
(:use "COMMON-LISP")
(:shadow "DEFUN" "DEFMACRO" "DEFVAR" "DEFPARAMETER" "DEFCONSTANT"
#| later add DEFINE-CONDITION, DEFPACKAGE, ...|#))
(in-package "MY-COMMON-LISP")
(common-lisp:defparameter *sources* (make-hash-table :test (function equal)))
(common-lisp:defmacro defun (name &rest stuff)
(setf (gethash (cons 'function name) *sources*) `(defun ,name ,@stuff))
`(common-lisp:defun ,name ,@stuff))
(common-lisp:defmacro defmacro (name &rest stuff)
(setf (gethash (cons 'function name) *sources*) `(defmacro ,name ,@stuff))
`(common-lisp:defmacro ,name ,@stuff))
(common-lisp:defmacro defvar (name &rest stuff)
(setf (gethash (cons 'variable name) *sources*) `(defvar ,name ,@stuff))
`(common-lisp:defvar ,name ,@stuff))
(common-lisp:defmacro defparameter (name &rest stuff)
(setf (gethash (cons 'variable name) *sources*) `(defparameter ,name ,@stuff))
`(common-lisp:defparameter ,name ,@stuff))
(common-lisp:defmacro defconstant (name &rest stuff)
(setf (gethash (cons 'variable name) *sources*) `(defconstant ,name ,@stuff))
`(common-lisp:defconstant ,name ,@stuff))
(defun source (symbol kind) (gethash (cons kind symbol) *sources*))
(defun edit (symbol &optional (kind 'function))
(let ((source (source symbol kind))
(tempfile (make-pathname
:name (format nil "TEMP~8,'0X" (random #x100000000))
:type "LIST" :case :common)))
(unwind-protect
;; NOTE: Here we could loop while there is an error in the load.
(progn (with-open-file (out tempfile
:direction :output
:if-exists :supersede
:if-does-not-exist :create)
(format out ";; -*- mode: lisp -*-~%~
;; Source for the ~A ~A~2%" kind symbol)
(when source (print source out)))
(ed tempfile)
(load tempfile))
(delete-file tempfile))))
(export 'source)
(export 'edit)
(export (let ((syms '()))
(do-symbols (s "COMMON-LISP")
(push (find-symbol (symbol-name s) *package*) syms))
syms))
(defpackage "MY-COMMON-LISP-USER"
(:nicknames "MY-CL-USER")
(:use "MY-COMMON-LISP"))
(in-package "MY-COMMON-LISP-USER")
(defun fact (x) (if (< 1 x) x (* x (fact (1- x)))))
(source 'fact 'function)
(defparameter fact '(--> (and (is sky blue) (is planet earth))
(is wheather good)))
(source 'fact 'variable)
(edit 'fact)
(source 'fact 'function)
(edit 'fact 'variable)
(source 'fact 'variable)
Or, if you don't want to bother, do as everybody else, edit the source
files in a unix file system with emacs, and only load them from the
REPL.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
From: Maks Romih
Subject: Re: Changing source on the fly
Date:
Message-ID: <uekceavp7.fsf@snt.si>
Thank you for explanation. I'm sorry I'm more of a beginner in lisp
folklore and patterns of thought, so I'm not sure I understand
everything.
GP lisper <········@CloudDancer.com> writes:
>
> ...
>
> Barry already answered this query. I don't use the debugger, "print"
> statement debugging is much faster and rarely leads you down the wrong
> path due to cascading errors. If you enjoy Visual Basic a lot, you
> should probably not use CMUCL, but try Allegro instead, as some claim
> it to be very much like VB.
>
I don't use the debugger only for debugging but sometimes for quick
writing of new code in the conext of some complicated state that is
not reproduced easily outside the application.
Let us say that I or my friend coded some algorythm some two years ago
and the algorythm is a part of a big application and I have to make a
small repair of this algorithm. I would put a break point somewhere in
the algorythm where approyimately I know the code will be changed and
then debugger shows me the local variables, their values etc. It helps
me remember and understand the code much quicker than any other means.
>
> Updating running source is simply done with two REPLs. CMUCL will
> give you a second REPL via telnet for:
>
> (setf mp::*idle-process* mp::*initial-process*)
> (mp::start-lisp-connection-listener :port 6789 :password "fred")
>
> NOTE: include the quotes for the password string in your telnet
>
> In the mentioned case, one REPL on a remote computer was parsing a 6.5
> hour long datastream, the second REPL received updated source via X
> 'cut-n-paste', after some quick testing (or not ;-) in a local slime.
Do I understand right that this second REPL runs concurrently in
another thread in the process that is parsing the data?
> Note that you can always test any part of Lisp at any time, if you
> have followed the guidelines that Paul Graham lays down for such an
> ability...i.e. definately worth doing! Thus some of the reasons you
> might employ a debugger no longer exist.
It was Paul Graham where I probably got the phrase "on the fly". The
fourth paragraph in section 5.6 of his "Hackers and Painters" begins
with:
"Our policy of fixing bugs on the fly changed the relationship..."
But in that book I didn't find more details about it. Can you tell me
in which of his three books or elsewhere the guidlines you talk about
are written. Unfortunately, as I see on Amazon, his "On LISP:
Advanced Techniques for Common LISP" is out of sale.
>
> --
> Everyman has three hearts;
> one to show the world, one to show friends, and one only he knows.
In article <·············@snt.si>, Maks Romih <·····@snt.si> wrote:
> > Note that you can always test any part of Lisp at any time, if you
> > have followed the guidelines that Paul Graham lays down for such an
> > ability...i.e. definately worth doing! Thus some of the reasons you
> > might employ a debugger no longer exist.
>
> It was Paul Graham where I probably got the phrase "on the fly". The
> fourth paragraph in section 5.6 of his "Hackers and Painters" begins
> with:
>
> "Our policy of fixing bugs on the fly changed the relationship..."
>
> But in that book I didn't find more details about it. Can you tell me
> in which of his three books or elsewhere the guidlines you talk about
> are written. Unfortunately, as I see on Amazon, his "On LISP:
> Advanced Techniques for Common LISP" is out of sale.
Maybe it's on his web site, www.paulgraham.com.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
On 11 May 2005 12:44:20 +0200, <·····@snt.si> wrote:
>
> Let us say that I or my friend coded some algorythm some two years ago
> and the algorythm is a part of a big application and I have to make a
> small repair of this algorithm. I would put a break point somewhere in
> the algorythm where approyimately I know the code will be changed and
> then debugger shows me the local variables, their values etc. It helps
> me remember and understand the code much quicker than any other means.
Well, one of the techniques of 'print' debugging is that you leave it
in place. You can code such debugging in such a fashion that it is
left out of any final version of the code. Many people make use of the
#+keyword mechanism for that purpose.
>> In the mentioned case, one REPL on a remote computer was parsing a 6.5
>> hour long datastream, the second REPL received updated source via X
>> 'cut-n-paste', after some quick testing (or not ;-) in a local slime.
>
> Do I understand right that this second REPL runs concurrently in
> another thread in the process that is parsing the data?
In the CMUCL sense for threads, yes. I bet you cannot do that in VB.
I am replacing a function in a loop, so the next time thru the loop,
the new function is active, as Barry Margolin pointed out previously.
When you read Sonya Keene's CLOS book, you'll see that I could be
sending a stream of Lisp objects to the remote lisp process instead.
> But in that book I didn't find more details about it. Can you tell me
> in which of his three books or elsewhere the guidlines you talk about
> are written. Unfortunately, as I see on Amazon, his "On LISP:
> Advanced Techniques for Common LISP" is out of sale.
'On Lisp' is available thru Grahams website and your local printer, or
through a pdf reader. In America, I had a bound copy made for $30,
but I also had obtained the book via interlibrary loan previously.
Perhaps something similar is available in your area.
Paul Grahams ideas are repeated in 'ANSI Common Lisp', in this
newsgroup, and in many websites, you really cannot miss them (and I
suspect that he was not the first to expound them). Other posters
have pointed out such places already. Reading c.l.l. has contributed
greatly to my Lisp education, the various books I'm reading are only
filling in minor cracks in that "possibility" knowledge. For
instance, the above telnet REPL information came from someone in this
newsgroup a few months ago.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
Maks Romih <·····@snt.si> writes:
> But in that book I didn't find more details about it. Can you tell me
> in which of his three books or elsewhere the guidlines you talk about
> are written. Unfortunately, as I see on Amazon, his "On LISP:
> Advanced Techniques for Common LISP" is out of sale.
Install UCW, and launch the example and admin web applications, then
go to http://localhost/ucw/admin and see how you get a REPL in the browser.
Alternatively, use a CL implementation with threads, and open a
slime/swank session with the UCW server while the "user" browse the
site.
Since I use clisp, I just break into the debugger, and edit the web
site "on the fly", eg. add or change methods and type continue and
reload the page, to fix bugs or to add features.
Actually, for any kind of application, this is the standard modus
operandi with lisp, since you always have the compiler and the
debugger available.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
Andr� Thieme <······························@justmail.de> writes:
> One question: in what language can you /not/ programm object oriented?
C++.
And I'm only _half_ joking.
From: Christopher C. Stacy
Subject: Re: Lisp Book(s) in the K&R Style
Date:
Message-ID: <uy8axl3wg.fsf@news.dtpq.com>
········@this.place writes:
> Are there any Lisp books in the style
> of "The C Programming Language" by K&R?
I haven't read that book since 1979, so I don't remember
the style at all. What was it that appealed to you?
······@news.dtpq.com (Christopher C. Stacy) wrote in
··················@news.dtpq.com:
> ········@this.place writes:
>
>> Are there any Lisp books in the style
>> of "The C Programming Language" by K&R?
>
> I haven't read that book since 1979, so I don't remember
> the style at all. What was it that appealed to you?
>
Tough to say but I'll try to explain.
There are several points already mentioned:
<quote>
- high quality prose
- exercises at the end of the chapters
- usable as a reference as well as a linear course of study
- concise
- written by people intimately familiar with the language
</quote>
Some other points that emerge from the ones mentioned:
- examples used to illustrate the language are the simplest
possible but yet useful enough to be reused in larger contexts.
- a style of coding that you are inspired to emulate.
- simplicity of exposition.
- the shortest distance between two points philosophy.
- a picture is worth 1000 words philosophy.
- elegance.
- all in a bit more than 200 pages.
- the "wow, I didn't know you could do that" in one line of code.
- did I mention the examples?
Paul F. Dietz wrote:
> RC wrote:
>
>> - exercises at the end of the chapters
>
> K&R had exercises?
Sure. There was also _The C Answer Book: Solutions to the
Exercises in The C Programming Language_, by Tondo and Gimpel, 1985.
--
Thomas M. Sommers -- ···@nj.net -- AB2SB
RC <··········@pvoalfotpmezsaq.net> writes:
> - examples used to illustrate the language are the simplest
> possible but yet useful enough to be reused in larger contexts.
>
> - a style of coding that you are inspired to emulate.
>
[snip]
>
> - did I mention the examples?
I like K&R, but some of the examples were elegant and simple because
they explicitly omitted error checking necessary for robustness.
Zach
Zach Beane <····@xach.com> writes:
> <··········@pvoalfotpmezsaq.net> writes:
>
> > - examples used to illustrate the language are the simplest
> > possible but yet useful enough to be reused in larger contexts.
> >
> > - a style of coding that you are inspired to emulate.
> >
> [snip]
> >
> > - did I mention the examples?
>
> I like K&R, but some of the examples were elegant and simple because
> they explicitly omitted error checking necessary for robustness.
Right, that would be correct C style. Fortunately for Lispers,
correct Lisp style and correct behavior go together.
I'm afraid that PAIP might be the best we have. It's huge, but
there's not really any filler in it, it's all content.
Alternately, On Lisp is a great example of a perfectly nice, if a
little quirky, style.
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in
····················@conquest.OCF.Berkeley.EDU:
> I'm afraid that PAIP might be the best we have. It's huge, but
> there's not really any filler in it, it's all content.
>
I've started looking at the PAIP source code and
I'm getting this error while loading auxfns.lisp:
CL-USER> (load "auxfns.lisp")
DEFUN/DEFMACRO(SYMBOL): #<PACKAGE COMMON-LISP> is locked
[Condition of type SYSTEM::SIMPLE-PACKAGE-ERROR]
Restarts:
0: [CONTINUE] Ignore the lock and proceed
1: [ABORT] Abort handling SLIME request.
It does not seem to affect loading (if you continue) but what does this
mean and is there a way to correct it?
This also happens while loading other modules.
Thanks
RC
> It does not seem to affect loading (if you continue) but what does this
> mean and is there a way to correct it?
This is one of the relatively few places where Lisp makes you "take
your medicine, it's good for you even if it tastes bad." You aren't
supposed to be able to modify system packages, and more and more
implementations are enforcing it.
To get rid of the continuable error, wrap the offending forms in a
WITHOUT-PACKAGE-LOCKS form. I should say, find what your system's
package-lock disabling method is and use it. In CMUCL it's
WITHOUT-PACKAGE-LOCKS.
--
Fred Gilham ······@csl.sri.com
When I was growing up, I found that the main argument against
laissez-faire, and for socialism, was that socialism and communism
were inevitable: "You can't turn back the clock!" they chanted, "you
can't turn back the clock." But the clock of the once-mighty Soviet
Union, the clock of Marxism-Leninism, a creed that once mastered half
the world, is not only turned back, but lies dead and broken forever.
-- Murray Rothbard
RC <··········@pvoalfotpmezsaq.net> writes:
> I've started looking at the PAIP source code and
> I'm getting this error while loading auxfns.lisp:
> [...]
> It does not seem to affect loading (if you continue) but what does this
> mean and is there a way to correct it?
PAIP was written at the CLtL2 times. I use the following loader
script. Define a NORVIG logical host with translations to the
directory where you put the code, eg.:
(setf (logical-pathname-translations "NORVIG")
'((#P"NORVIG:**;*.*" #P"/home/pjb/src/lisp/norvig/**/*.*")
(#P"NORVIG:**;*" #P"/home/pjb/src/lisp/norvig/**/*")))
;; then:
(load "norvig.lisp"
(in-package "COM.NORVIG")
; have fun!
;;****************************************************************************
;;FILE: norvig.lisp
;;LANGUAGE: Common-Lisp
;;SYSTEM: -
;;USER-INTERFACE: -
;;DESCRIPTION
;;
;; Loaded for Norvig's code
;;
;;AUTHORS
;; <PJB> Pascal Bourguignon
;;MODIFICATIONS
;; 2003-05-14 <PJB> Created.
;;BUGS
;;LEGAL
;; GPL
;;
;; Copyright Pascal Bourguignon 2003 - 2003
;; ··········@informatimago.com
;;
;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License
;; as published by the Free Software Foundation; either version
;; 2 of the License, or (at your option) any later version.
;;
;; This program is distributed in the hope that it will be
;; useful, but WITHOUT ANY WARRANTY; without even the implied
;; warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
;; PURPOSE. See the GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public
;; License along with this program; if not, write to the Free
;; Software Foundation, Inc., 59 Temple Place, Suite 330,
;; Boston, MA 02111-1307 USA
;;****************************************************************************
(defpackage "COM.NORVIG"
(:use "COMMON-LISP")
(:SHADOW "EXP"))
(in-package "COM.NORVIG")
(DEFPARAMETER CONFIGURATION
'(GPS-SEARCH ELISA-PM PROLOG-CP KREP SYNTAX-3 SCHEME-3 SCHEME-C3))
(DEFMACRO EXCLUSIVE (&REST E-B)
(LET ((ETIQUETTES (MAPCAR (FUNCTION CAR) E-B))
(REP (GENSYM "REP")))
`(LET ((,REP (INTERSECTION CONFIGURATION ',ETIQUETTES)))
(IF (= 1 (LENGTH ,REP))
(PROGN
(SETQ ,REP (CAR ,REP))
(FORMAT T "~&CONFIGURED: ~A~%" ,REP))
(SETQ ,REP
(DO ((,REP NIL))
(,REP ,REP)
(FORMAT *QUERY-IO* "~&Please choose what to load from ~S: "
',ETIQUETTES)
(SETQ ,REP (READ *QUERY-IO*))
(UNLESS (MEMBER ,REP ',ETIQUETTES) (SETQ ,REP NIL)))))
(CASE ,REP
,@E-B))))
(DEFVAR *PAIP-SOURCE-FILES*
(TRANSLATE-LOGICAL-PATHNAME (MAKE-PATHNAME
:HOST "NORVIG"
:DIRECTORY '(:ABSOLUTE)
:NAME NIL
:TYPE "LISP"))
"The location of the source files for this book.
CHANGE IT TO REFLECT THE LOCATION OF THE FILES ON YOUR COMPUTER.")
(LOAD "norvig:intro.lisp") ;; A few simple definitions
(LOAD "norvig:simple.lisp") ;; Random sentence generator (two versions)
(LOAD "norvig:overview.lisp") ;; 14 versions of LENGTH and other examples
(LOAD "norvig:auxmacs.lisp") ;; A few macros; load this first.
(UNLESS (FBOUNDP 'COMMON-LISP:LOOP)
(LOAD "norvig:loop.lisp")) ;; Load if your Lisp doesn't support ANSI LOOP
(LOAD "norvig:auxfns.lisp") ;; Commonly used auxiliary functions.
(LOAD "norvig:search.lisp") ;; Search Utility
;; "norvig:search.dat" ;; Test data (examples) for above
(EXCLUSIVE
(GPS-SIMPLE
(LOAD "norvig:gps1.lisp") ;; Simple version of General Problem Solver
;; "norvig:gps1.dat" ;; Test data (examples) for above
)
(GPS
(LOAD "norvig:gps1.lisp") ;; Simple version of General Problem Solver
(LOAD "norvig:gps.lisp") ;; Final version of General Problem Solver
;; "norvig:gps.dat" ;; Test data (examples) for above
)
(GPS-SEARCH
(LOAD "norvig:gps1.lisp") ;; Simple version of General Problem Solver
(LOAD "norvig:gps.lisp") ;; Final version of General Problem Solver
(LOAD "norvig:gps-srch.lisp") ;; Version of GPS using the search utility
;; "norvig:gps-srch.dat" ;; Test data (examples) for above
))
(LOAD "norvig:patmatch.lisp") ;; Pattern Matching Utility
;; "norvig:patmatch.dat" ;; Test data (examples) for above
(EXCLUSIVE
(ELISA-BASIC
(LOAD "norvig:eliza1.lisp") ;; Basic version of Eliza program
)
(ELISA
(LOAD "norvig:eliza.lisp") ;; Eliza with more rules; different reader
)
(ELISA-PM
(LOAD "norvig:eliza-pm.lisp") ;; Version of Eliza using utilities
(LOAD "norvig:cmacsyma.lisp") ;; Efficient Macsyma with canonical form
;; "norvig:cmacsyma.dat" ;; Test data (examples) for above
))
(LOAD "norvig:student.lisp") ;; The Student Program
;; "norvig:student.dat" ;; Test data (examples) for above
(LOAD "norvig:macsyma.lisp") ;; The Macsyma Program
(LOAD "norvig:macsymar.lisp") ;; Simplification & integration rules for Macsyma
;; "norvig:macsyma.dat" ;; Test data (examples) for above
(LOAD "norvig:unify.lisp") ;; Unification functions
(EXCLUSIVE
(PROLOG1
(LOAD "norvig:prolog1.lisp") ;; First version of Prolog interpreter
;; "norvig:prolog1.dat" ;; Test data (examples) for above
)
(PROLOG
(LOAD "norvig:prolog.lisp") ;; Final version of Prolog interpreter
;; "norvig:prolog.dat" ;; Test data (examples) for above
)
(PROLOG-C1
(LOAD "norvig:prologc1.lisp") ;; First version of Prolog compiler
;; "norvig:prologc1.dat" ;; Test data (examples) for above
)
(PROLOG-C2
(LOAD "norvig:prologc2.lisp") ;; Second version of Prolog compiler
;; "norvig:prologc2.dat" ;; Test data (examples) for above
)
(PROLOG-C
(LOAD "norvig:prologc.lisp") ;; Final version of Prolog compiler
;; "norvig:prologc.dat" ;; Test data (examples) for above
)
(PROLOG-CP
;;(LOAD "norvig:prologcp.lisp") ;; Primitives for Prolog compiler
;;(LOAD "norvig:unifgram.lisp") ;; Unification Parser
;; "norvig:unifgram.dat" ;; Test data (examples) for above
;;(LOAD "norvig:lexicon.lisp") ;; Sample Lexicon of English
;; "norvig:grammar.dat" ;; Test data (examples) for above
(LOAD "norvig:grammar.lisp") ;; Comprehensive grammar of English
))
(LOAD "norvig:clos.lisp") ;; Some object-oriented and CLOS code
;; "norvig:clos.dat" ;; Test data (examples) for above
(EXCLUSIVE
(KREP-1
(LOAD "norvig:krep1.lisp") ;; Knowledge Representation code: first version
;; "norvig:krep1.dat" ;; Test data (examples) for above
)
(KREP-2
(LOAD "norvig:krep2.lisp") ;; Knowledge Representation code w/ conjunctions
)
(KREP
(LOAD "norvig:krep.lisp") ;; Final KR code: worlds and attached functions
))
(LOAD "norvig:mycin.lisp") ;; The Emycin expert system shell
(LOAD "norvig:mycin-r.lisp") ;; Some rules for a medical application of emycin
;; "norvig:mycin.dat" ;; Test data (examples) for above
(LOAD "norvig:waltz.lisp") ;; A Line-Labeling program using Waltz algorithm
;; "norvig:waltz.dat" ;; Test data (examples) for above
;; (LOAD "norvig:othello.lisp") ;; The Othello playing program & strategies
;; "norvig:othello.dat" ;; Test data (examples) for above
(LOAD "norvig:othello2.lisp") ;; Additional strategies for Othello
(LOAD "norvig:edge-tab.lisp") ;; Edge table for Iago strategy
(EXCLUSIVE
(SYNTAX-1
(LOAD "norvig:syntax1.lisp") ;; Syntactic Parser
;; "norvig:syntax1.dat" ;; Test data (examples) for above
)
(SYNTAX-2
(LOAD "norvig:syntax2.lisp") ;; Syntactic Parser with semantics
;; "norvig:syntax2.dat" ;; Test data (examples) for above
)
(SYNTAX-3
(LOAD "norvig:syntax3.lisp") ;; Syntactic Parser with semantics and pref.
;; "norvig:syntax3.dat" ;; Test data (examples) for above
))
(EXCLUSIVE
(SCHEME-1
(LOAD "norvig:interp1.lisp") ;; Scheme interpreter, incl. version with macros
;; "norvig:interp1.dat" ;; Test data (examples) for above
)
(SCHEME-2
(LOAD "norvig:interp1.lisp") ;; Scheme interpreter, incl. version with macros
(LOAD "norvig:interp2.lisp") ;; A tail recurive Scheme interpreter
)
(SCHEME-3
(LOAD "norvig:interp1.lisp") ;; Scheme interpreter, incl. version with macros
(LOAD "norvig:interp3.lisp") ;; A Scheme interpreter that handles call/cc
;; "norvig:interp3.dat" ;; Test data (examples) for above
))
(EXCLUSIVE
(SCHEME-C1
(LOAD "norvig:compile1.lisp") ;; Simple Scheme compiler
)
(SCHEME-C2
(LOAD "norvig:compile2.lisp") ;; Compiler with tail recursion and primitives
)
(SCHEME-C3
(LOAD "norvig:compile3.lisp") ;; Compiler with peephole optimizer
(LOAD "norvig:compopt.lisp") ;; Peephole optimizers for compile3.lisp
;; "norvig:compile.dat" ;; Test data (examples) for all 3 versions above
))
;;;; norvig.lisp -- 2003-05-16 07:54:59 -- pascal ;;;;
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
········@this.place wrote:
> Are there any Lisp books in the style
> of "The C Programming Language" by K&R?
I second the comparison to Graham's "ANSI Common Lisp".
Both start with a tutorial. Then both have a series of more
advanced explanations. Then both end with a reference section.