How can I learn not only the syntax of Lisp, but also the way of
developing applications? If one hasn't used things like macros &
incremental development it's often very difficult to use them in an
elegant way. Is On Lisp a good way to learn?
Thanks,
Jules
Jules wrote:
> How can I learn not only the syntax of Lisp, but also the way of
> developing applications? If one hasn't used things like macros &
> incremental development it's often very difficult to use them in an
> elegant way. Is On Lisp a good way to learn?
>
> Thanks,
>
> Jules
I am learning lisp too, and find that reading existing application
source code from various packages listed on http://www.cliki.net is
also good resource. Just pick your category and pick your application
and learn what the code does line by line.
For language reference you can use Hyperspec at
http://www.lisp.org/HyperSpec/FrontMatter/index.html
Can anyone recommend other source of reference for the language and
commonly used libraries in HTML documentation form like the Hyperspec?
Alok
On Sun, 27 Aug 2006 12:10:32 -0700, Alok wrote:
> Jules wrote:
> Can anyone recommend other source of reference for the language and
> commonly used libraries in HTML documentation form like the Hyperspec?
>
> Alok
CFFI[1] has a good manual. Most of the things written by Edi Weitz is also
documented: http://weitz.de/ - cl-ppcre is commonly used.
[1]: http://common-lisp.net/project/cffi/manual/html_node/index.html
--
Lars Rune Nøstdal
http://lars.nostdal.org/
The best book i ever read about programming is PAIP.
http://www.norvig.com/paip.html
Jules wrote:
> How can I learn not only the syntax of Lisp, but also the way of
> developing applications? If one hasn't used things like macros &
> incremental development it's often very difficult to use them in an
> elegant way. Is On Lisp a good way to learn?
>
> Thanks,
>
> Jules
Fractal <···········@gmail.com> wrote:
> The best book i ever read about programming is PAIP.
> http://www.norvig.com/paip.html
Really boring when you're not interested in AI.
First of all I find it hard to believe that a lisp programmer won't
find AI interesting. Norvig uses AI examples to present the lisp way of
doing things - think out of the box about the problem at hand,
without locking your mind with a certain paradigm, language,
whatever...
Stefan Scholl wrote:
> Fractal <···········@gmail.com> wrote:
> > The best book i ever read about programming is PAIP.
> > http://www.norvig.com/paip.html
>
> Really boring when you're not interested in AI.
Stefan Scholl <······@no-spoon.de> writes:
> Fractal <···········@gmail.com> wrote:
> > The best book i ever read about programming is PAIP.
> > http://www.norvig.com/paip.html
>
> Really boring when you're not interested in AI.
Not at all. It has very little to do with "real" AI, and much to do
with the programming techniques that were discovered in the quest for
what was historically considered AI. The techniques are useful and
applicable for many things today. The "52 lessons of PAIP" on
http://www.norvig.com/Lisp-retro.html are invaluable.
Zach
On Sun, 27 Aug 2006 22:58:16 +0200, Stefan Scholl <······@no-spoon.de>
wrote:
> Fractal <···········@gmail.com> wrote:
>> The best book i ever read about programming is PAIP.
>> http://www.norvig.com/paip.html
>
> Really boring when you're not interested in AI.
>
Well I am interested in AI but even if I wasn't
I think I would find the book useful.
For one thing it is one of the only good texts on
optimizing Lisp. The Lisp efficiency model is somewhat difficult
to 'grook'. Certainly I didn't find the book boring.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On 2006-08-27 14:26:52 -0400, "Jules" <···········@gmail.com> said:
> How can I learn not only the syntax of Lisp, but also the way of
> developing applications? If one hasn't used things like macros &
> incremental development it's often very difficult to use them in an
> elegant way. Is On Lisp a good way to learn?
Not so much - On Lisp is an advanced text for programmers who are
either experienced lispers/schemers or who have a fairly deep knowledge
of programming and computer science.
If you want a hands-on, real world approach, I and many others on this
list would recommend Peter Siebel's Practical Common Lisp. In addition
he frequents c.l.l so he might take the time to answer anything you're
stuck on as you work you way through his book.
Paul Graham's other lisp book - ANSI Common Lisp is intended as an
introduction to common lisp, so if you want to read Graham, read ANSI
Common Lisp, or Peter Siebel's PCL first, then move on to On Lisp.
good luck learning lisp
Ralph
On Sun, 27 Aug 2006 11:26:52 -0700, Jules wrote:
> How can I learn not only the syntax of Lisp, but also the way of
> developing applications? If one hasn't used things like macros &
> incremental development it's often very difficult to use them in an
> elegant way. Is On Lisp a good way to learn?
>
> Thanks,
>
> Jules
I'd go for "Practical Common Lisp"[1] first then read "On Lisp" later.
[1]: http://www.gigamonkeys.com/book/
--
Lars Rune Nøstdal
http://lars.nostdal.org/
"Jules" <···········@gmail.com> writes:
> How can I learn not only the syntax of Lisp, but also the way of
> developing applications? If one hasn't used things like macros &
Start with Practical Common Lisp:
http://www.gigamonkeys.com/book
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
"Jules" <···········@gmail.com> writes:
>
> How can I learn not only the syntax of Lisp, but also the way of
> developing applications? If one hasn't used things like macros &
> incremental development it's often very difficult to use them in an
> elegant way. Is On Lisp a good way to learn?
I can't speak regarding On Lisp, although I will say that I found ANSI
Common Lisp to be far too basic an introduction.
Get a copy of Practical Common Lisp, an implementation of your choice (I
like SBCL), a copy of emacs & of SLIME, then start hacking. If web
programming is your thing, then you might like Webactions (which runs
atop AllegroServe/PortableAllegroServe); I've been porting my beer
tasting notes application over to it and have been very pleased so far.
It fits my mind better than araneida, but that's also supposed to be a
nice solution.
The best way to learn how to develop apps is to develop them. With a
running SLIME connected to my web server process, life is pretty grand:
I can dynamically recompile functions, redefine data structures and in
general have a fine time playing with my app.
It works for me, anyway--YMMV.
--
Robert Uhl <http://public.xdi.org/=ruhl>
To me, elitism means a love of excellence and superiority, but America
has declared war on both and developed a sick love of the lowest common
denominator to make sure no-one becomes too fine for our touted
democracy. We are almost at the point of regarding every virtue as
elitist. --Florence King
This is an interesting subject.
Like, the notion of 'unwinding', or of 'macro-expansion', and how to procede
once we are dropped into a debugger after an error (normally abort back to
the top-level, struggle to interpret the error message, and look again for
simple errors at the last point that the code was tinkered with).
In other words, novices are probably struggling with their debugging.
A good explanation of these issues is indeed hard to find.
Adam <······@example.com> writes:
> This is an interesting subject.
>
> Like, the notion of 'unwinding', or of 'macro-expansion', and how to procede
> once we are dropped into a debugger after an error (normally abort back to
> the top-level, struggle to interpret the error message, and look again for
> simple errors at the last point that the code was tinkered with).
>
> In other words, novices are probably struggling with their debugging.
>
> A good explanation of these issues is indeed hard to find.
Here is a new cliki page: http://www.cliki.net/TutorialClispDebugger
Debugging is implementation dependant.
With clisp, debugging can only be done on interpreted functions. Too
little information remains in compiled functions to do any useful
debugging.
So, let's take care not to compile our new functions:
[221]> (defun fact (x) (if (< x 1) (/ 1 x) (* x (fact (1- x)))))
FACT
[222]> (defun pf (n) (loop :for i :from n :downto 1 :do (print `(,i ,(fact i)))))
PF
[223]> (pf 4)
*** - division by zero
The following restarts are available:
ABORT :R1 ABORT
Break 1 [224]>
The first thing to do, is to dump the stack backtrace. Often, this is
all you'll have to do to identify and correct the bug, because clisp
displays a lot of information about non compiled functions:
Break 1 [224]> :bt
<1> #<SYSTEM-FUNCTION EXT:SHOW-STACK> 3 ; These frames correspond
<2> #<COMPILED-FUNCTION SYSTEM::PRINT-BACKTRACE> ; to compiled functions
<3> #<COMPILED-FUNCTION SYSTEM::DEBUG-BACKTRACE> ; belonging to the
<4> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> 2 ; debugged itself.
<5> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2-2> ; Notice how little
<6> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS> 2 ; information we have:
<7> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2> ; only the function name.
<8> #<SYSTEM-FUNCTION SYSTEM::DRIVER> ;
<9> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP> ;
<10> #<SYSTEM-FUNCTION INVOKE-DEBUGGER> 1 ;
<11> #<SYSTEM-FUNCTION /> 2 ; the divide function call
; who raised the error.
<12> #<SPECIAL-OPERATOR IF>
; And here we have the form from our code
; who called / with a zero divisor.
; Happily, it's the only division in the form
; so we can identify it immediately.
EVAL frame for form (IF (< X 1) (/ 1 X) (* X (FACT (1- X))))
APPLY frame for call (FACT '0)
<13>
#<FUNCTION FACT (X) (DECLARE (SYSTEM::IN-DEFUN FACT))
(BLOCK FACT (IF (< X 1) (/ 1 X) (* X (FACT (1- X)))))> 1
EVAL frame for form (FACT (1- X))
EVAL frame for form (* X (FACT (1- X)))
<14> #<SPECIAL-OPERATOR IF>
EVAL frame for form (IF (< X 1) (/ 1 X) (* X (FACT (1- X))))
APPLY frame for call (FACT '1)
[...]
EVAL frame for form
(LET ((I N))
(LET NIL
(TAGBODY SYSTEM::BEGIN-LOOP (WHEN (< I 1) (GO SYSTEM::END-LOOP))
(PRINT (LIST I (FACT I))) (PSETQ I (- I 1)) (GO SYSTEM::BEGIN-LOOP)
SYSTEM::END-LOOP)))
APPLY frame for call (PF '4)
<25>
#<FUNCTION PF (N) (DECLARE (SYSTEM::IN-DEFUN PF))
(BLOCK PF (LOOP :FOR I :FROM N :DOWNTO 1 :DO (PRINT `(,I ,(FACT I)))))> 1
EVAL frame for form (PF 4)
Printed 25 frames
Break 1 [224]>
But let's assume that there was another division in the other branch
of the IF. How could we know what branch was being executed? We
could re-evaluate the condition. First move up the frames to the EVAL
frame, were we'll have access to the lexical variables. Only one :u
command is needed because it skips over the compiled frames where we
cannot get at the lexical variables (they might be optimized out!).
Break 1 [224]> :u
<1> #<SPECIAL-OPERATOR IF>
EVAL frame for form (IF (< X 1) (/ 1 X) (* X (FACT (1- X))))
Then we can enter any lisp form, like the condition:
Break 1 [224]> (< X 1)
T
and see that it's the "then" branch that was taken, and therefore it's
(/ 1 X) which raises the error. Let's check that X is 0:
Break 1 [224]> x
0
Indeed.
Now, we have the choice of aborting the debuging session and going
back to the source file to correct the bug, reload the file, or just
reevaluate the defun, and run it again, or try to correct the bug
inside the debugger, and proceed from there.
In the first case, we can use :q to go back to the toplevel.
In the second case, let's redefine fact:
Break 1 [224]> (defun fact (x) (if (< x 1) 1 (* x (fact (1- x)))))
FACT
then we return from the failed EVAL frame, giving the result it should
return:
Break 1 [224]> :rt
Values: 1
(4 24)
(3 6)
(2 2)
(1 1)
NIL
[225]>
And we see:
1- how the current call (fact 4) proceeds to completion, and
2- how the next calls (fact 3) ... (fact 1) invoke the new function.
Note that if the failed EVAL frame had been in a loop inside the
function, the loop would still call iteratively the wrong version.
The new version of the function is only taken into account for the new
function calls. To proceed in such a case, we would have to move up
the frames (:u) until we could return (:rt) from the whole function.
--
__Pascal Bourguignon__ http://www.informatimago.com/
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
Wow. Very many thanks, Pascal.
I'll take a look at the wiki. But I must say, your service to this
newsgroup is fantastic and very much apprecated. Others too, of course.
FYI: No - I am not studying Lisp at school or college - but have been using
it for 2 or 3 years now with an application. And feel I am only just
starting to 'get' it, in preference to Elisp or anything else (like Slime).
So, very many thanks for progressing us novices that much further.
Adam.