I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
the first couple of chapters and I have to say that, by and large, I'm
lost.
Now, I consider myself to be a fairly intelligent guy, and I'm able to
pick up other (imperative) languages fairly quickly, but Lisp is just
giving my brain a serious run for its money. Is this normal? Am I reading
the wrong book? Am I going about this the wrong way? I know that
reading/writing code in a language is the best way to learn it, but (for
example) I've spent about 3 hours total staring at one example from the
book (3.12, page 52 for those who are interested), and it seriously has me
baffled.
I've been told (and read on several different sites) that learning Lisp
will change the way you look at programming. I'm excited about this
"enlightenment", but frustrated at the fact that it's not coming very
easily to me...
Any suggestions?
Thanks in advance!!
Brett Kelly <·······@inkedmn.com> wrote in message news:<·····························@inkedmn.com>...
>
....
> Any suggestions?
>
> Thanks in advance!!
try Slade's "Object Oriented Common Lisp" or Winston/Horn.
don't expect to pick up Lisp within a couple of weeks: it needs
patience to reach the Zen. ;-)
-klaus.
Brett Kelly <·······@inkedmn.com> wrote in message news:<·····························@inkedmn.com>...
> I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
Ok, that code is no longer meant to be read. ;) Nowadays the hot
thing is network programming and multimedia utils; back then I guess
the big market was for people who cared about stuff like search
strategies. So "breadth-first searches" would've been common
knowledge for most readers, but that is no longer the case.
I strongly suggest that you feel free to skip those things. It is not
interesting unless you find it interesting. If it drives you nuts to
see code you don't grok, I'm sure I or someone else can explain it.
My main strategy in learning something new is to find multiple sources
and observe their perspectives. People have found these two to be
particularly useful:
- http://www.gigamonkeys.com/book/
This has pretty cool practicals where you build mp3 databases and unit
testing frameworks. Also the story he made up to explain macros is
probably the best I've seen.
- http://www-2.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html
Really explains some stuff well; I own the dead-tree version.
- http://www.psg.com/~dlamkins/sl/contents.html
I'm not too familiar with this, but it seems clean and helpful.
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
As I understand it, lisp's reason for existence is to be a very
moldable substance from which to hang good ideas.
As an example, one good idea is the way lispers write code in a data
structure (data format) that is probably lisp's simplest datatype, so
it's not hard to manipulate programs like you would any piece of data.
No complicated text parsers or anything, you can just create a new
control construct like a for() loop, or whatever else makes your code
cleaner. This helps support the "moldable" part.
http://lambda.pentaside.org/article/symbols.html
Another good idea is that pieces of code on the calling chain can
communicate with each other. Think of how C# exceptions work; when
you throw one, the exception destructively bursts through the call
chain, only slowing down for finally clauses, until it's caught. But
sometimes you just want to safely freeze the chain for a while, as
your code figures out how to deal with an unusual situation like when
the disk becomes full during a write. When you call a
highly-recommended library that performs the write, it doesn't know if
it should pop up a dialog box or page the admins. Only you do. But
it does document some tactics useful to you, like going back right
before the write to retry it, deleting its unused tempfiles, or
aborting safely. So your app could choose to silently ask it to
delete the tempfiles, and if that doesn't work, you can pop up the
abort/retry/save-elsewhere dialog box. When it's all taken care of,
the chain can be unfrozen.
And it doesn't have to be for serious errors. If the lib notices the
disk is remarkably low on space, but not enough to be an immediate
problem, it can release a warning that can be ignored. In an
iTunes-type app, it might unobtrusively warn the user. For highly
polished apps that users like, these things can be important. And a
big win of this is you don't have to bake in the errorhandling
strategy from day one; it can be a refinement when you have the basic
app down.
Things like this make lisp important for writing real-world apps. And
that's sort of the tip of the iceberg. Heijlsberg is already baking
in lisp stuff like lambda and closures into the next version of C#.
There's more good stuff to steal, as the C# userbase gets used to
these incremental changes.
Um... if this sounds like a big long marketing spiel, I'm just trying
to figure out how to convey this "enlightenment." One day I'll have
to teach it; a friend asked me if one day I'd show her what it's all
about. So I'm basically practicing. ;)
Brett Kelly <·······@inkedmn.com> writes:
>
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
> the wrong book? Am I going about this the wrong way? I know that
> reading/writing code in a language is the best way to learn it, but (for
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
I think that is normal, even for fairly intelligent guys. :-)
I read ANSI Common Lisp myself when I was a complete newbie, and I remember
this example very good having spendt everal hours trying to grasp it. When
I look at it now, I grasp it pretty much right away.
My advise is to skip it and continue reading. If something takes you more
than an hour to understand, just mark for for later an read ahead. You
don't lear much by banging your head in a single example for longer than
this.
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
Isn't it a saying in english that "Good things don't come easy"?
I think the first few chapters are relatively hard compared to the rest
of the book, but remember that it's only 300 pages plus reference for a
pretty large language...
By the way, what kind of development environment do you use? The first
time I tried to lean Lisp, I used the edit/compile/run cycle just like
I did in C. Needless to say, may first attempt at Lisp failed...
--
We tend to meet any new situation by reorganising; and a wonderful method
it can be for creating the illusion of progress while producing confusion,
inefficiency and demoralisation. -- Gaius Petronius, 60 AD
Brett Kelly wrote:
> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
> the first couple of chapters and I have to say that, by and large, I'm
> lost.
>
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
> the wrong book? Am I going about this the wrong way? I know that
> reading/writing code in a language is the best way to learn it, but (for
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
>
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
>
> Any suggestions?
You should see the same algorithm in C#. :)
That is one nasty (tricky) example, made harder by Graham's aversion to
OO, so you have to keep reminding yourself what the cars and cdrs are.
Come to think of it, C# would force you to use meaningful datanames for
the structure elements, so the code would be clearer. I have been
working at Lisp hardcore for eight years and could not make out at first
what was going on.
Maybe try Peter's upcoming book*:
<http://www.gigamonkeys.com/book/>
He is calling the book "Practical Lisp", and is himself a recent emigre
from the land of Java. Come back to Graham when you have five thousand
lines of Lisp under your belt.
kt
[peter: hurry up! the noobs have arrived!! (good timing, btw)]
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Brett Kelly wrote:
>> Am I reading the wrong book?
I began to learn Lisp with _ANSI Common Lisp_, but I haven't opened it
since I first read it. It's not a great reference (compared to the
keystrokes-away HyperSpec), and the style it uses in examples doesn't
seem typical now that I've read other books and looked at other
code.
The things that stuck in my mind at the time were the straightforward
way it constructs a raytracer and and an object system, though the
latter poisoned my mind for a time to the usefulness of CLOS.
I think Peter Norvig's _Paradigms of AI Programming_ might be a better
book for learning Common Lisp. Though it covers a lot more ground,
it's nice not to have to get separate books to learn about
interpreting disassembly, profiling and optimization, compilation
techniques, debugging, and more.
>> example) I've spent about 3 hours total staring at one example from the
>> book (3.12, page 52 for those who are interested), and it seriously has me
>> baffled.
>
> You should see the same algorithm in C#. :)
>
> That is one nasty (tricky) example, made harder by Graham's aversion
> to OO, so you have to keep reminding yourself what the cars and cdrs
> are. Come to think of it, C# would force you to use meaningful
> datanames for the structure elements, so the code would be clearer. I
> have been working at Lisp hardcore for eight years and could not make
> out at first what was going on.
I like
<http://www.cs.northwestern.edu/academics/courses/325/readings/graham/graham-notes.html>
as a guide to where _ANSI Common Lisp_ is notably weird.
Zach
Brett Kelly wrote:
> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
> the first couple of chapters and I have to say that, by and large, I'm
> lost.
>
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
> the wrong book? Am I going about this the wrong way? I know that
> reading/writing code in a language is the best way to learn it, but (for
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
>
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
>
> Any suggestions?
>
> Thanks in advance!!
Graham's book is a great book (later you should read this one too:
http://www.paulgraham.com/onlisptext.html), but for starters this might
be easier:
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/dst/www/LispBook/index.html
Take a look at Graham's site:
http://www.paulgraham.com/booklinks.html
Ahh, Figure 3.12: Breadth-first search, I remember it well.
That and Figure 4.5: Binary search trees are the two hardest
figures in the book. I ended up skipping those two and going
back to them later after I was more familiar with Lisp.
Strangely enough, looking back, it is a hard to see what was
so difficult. So rest assured, it will click and afterwards
you will wonder what was so difficult about it.
Here is Graham's code:
(defun shortest-path (start end net)
(bfs end (list (list start)) net))
(defun bfs (end queue net)
(if (null queue)
nil
(let ((path (car queue)))
(let ((node (car path)))
(if (eql node end)
(reverse path)
(bfs end
(append (cdr queue)
(new-paths path node net))
net))))))
(defun new-paths (path node net)
(mapcar #'(lambda (n)
(cons n path))
(cdr (assoc node net))))
Notice that he does not use free variables. Nothing happens
to END and NET. They are just passed on unchanged to where
they are needed. So they could be global variables, which
would get them out of the parameter lists so one could focus
attention on the parameter that is different from call to
call.
END and NET are not very catchy names. This is a search
problem, call them NEEDLE and HAYSTACK.
(defvar needle 'd)
(defvar haystack '((a b c)(b c)(c d)(d)))
It is worth pondering how much of the difficulty comes from
the extremely austere representation of the graph. One is
perhaps expecting to see
'(graph
(node-list (a b c d))
(parent a child-list (b c))
(parent b child-list (c))
(parent c child-list (d))
(parent d child-list ())))
Let's define an accessor for the child list:
(defun child-list(parent)
(cdr (assoc parent haystack)))
Lisp's built-in lists are singly linked, so one tries to
ensure that ones code always works on the beginning (left)
not the end (right). Thus the code is representing paths
through the graph in reverse order. The "end" is the first
element, not the last. We can protect ourselves from
confusion with
(defun active-node(path)
(car path))
so Graham's new-paths could be rewritten
(defun list-of-extensions-of (base-path)
(mapcar #'(lambda(new-node)(cons new-node base-path))
(child-list (active-node base-path))))
One tries it out at the REPL
(list-of-extensions-of '(a before before-that))
=> ((B A BEFORE BEFORE-THAT) (C A BEFORE BEFORE-THAT))
One more little function to tidy up the end test:
(defun touches-needle-p (path)
(eql needle (car path)))
Then we can rewrite BFS as
(defun bfs2 (list-of-paths)
(if (null list-of-paths) nil
(let ((current-path (car list-of-paths)))
(if (touches-needle-p current-path)
(reverse current-path); bfs2 returns from here
(bfs2 (append (cdr list-of-paths)
(list-of-extensions-of current-path)))))))
I doubt that this helps very much. That is OK. The point is
to go
(trace bfs2 child-list active-node list-of-extensions-of touches-needle-p)
(bfs '((a)))
and get a readable trace
0: (BFS2 ((A)))
1: (TOUCHES-NEEDLE-P (A))
1: TOUCHES-NEEDLE-P returned NIL
1: (LIST-OF-EXTENSIONS-OF (A))
2: (ACTIVE-NODE (A))
2: ACTIVE-NODE returned A
2: (CHILD-LIST A)
2: CHILD-LIST returned (B C)
1: LIST-OF-EXTENSIONS-OF returned ((B A) (C A))
1: (BFS2 ((B A) (C A)))
2: (TOUCHES-NEEDLE-P (B A))
2: TOUCHES-NEEDLE-P returned NIL
2: (LIST-OF-EXTENSIONS-OF (B A))
3: (ACTIVE-NODE (B A))
3: ACTIVE-NODE returned B
3: (CHILD-LIST B)
3: CHILD-LIST returned (C)
2: LIST-OF-EXTENSIONS-OF returned ((C B A))
2: (BFS2 ((C A) (C B A)))
3: (TOUCHES-NEEDLE-P (C A))
3: TOUCHES-NEEDLE-P returned NIL
3: (LIST-OF-EXTENSIONS-OF (C A))
4: (ACTIVE-NODE (C A))
4: ACTIVE-NODE returned C
4: (CHILD-LIST C)
4: CHILD-LIST returned (D)
3: LIST-OF-EXTENSIONS-OF returned ((D C A))
3: (BFS2 ((C B A) (D C A)))
4: (TOUCHES-NEEDLE-P (C B A))
4: TOUCHES-NEEDLE-P returned NIL
4: (LIST-OF-EXTENSIONS-OF (C B A))
5: (ACTIVE-NODE (C B A))
5: ACTIVE-NODE returned C
5: (CHILD-LIST C)
5: CHILD-LIST returned (D)
4: LIST-OF-EXTENSIONS-OF returned ((D C B A))
4: (BFS2 ((D C A) (D C B A)))
5: (TOUCHES-NEEDLE-P (D C A))
5: TOUCHES-NEEDLE-P returned T
4: BFS2 returned (A C D)
3: BFS2 returned (A C D)
2: BFS2 returned (A C D)
1: BFS2 returned (A C D)
0: BFS2 returned (A C D)
The graph itself has been tidied away into a global
variable, so it is no longer cluttering up the trace
output.
The driver routine looks like this:
(defun shortest-path2 (start end graph)
(let ((needle end)
(haystack graph))
(bfs2 (list (list start)))))
Example: (shortest-path2 'ma-jones 'samsara-smith
'((ma-jones ethel-stevenson maud-campbell)
(ethel-stevenson mary-stevenson jane-black elizabeth-white)
(maud-campbell susan-smith fiona-brown)
(elizabeth-white peaches-white trixie-bell-white)
(fiona-brown moonbeam-brown sunshine-brown)
(susan-smith nirvana-smith samsara-smith)))
=> (MA-JONES MAUD-CAMPBELL SUSAN-SMITH SAMSARA-SMITH)
Brett Kelly also worries:
> Now, I consider myself to be a fairly intelligent guy, and
> I'm able to pick up other (imperative) languages fairly
> quickly, but Lisp is just giving my brain a serious run
> for its money. Is this normal? Am I reading the wrong
> book? Am I going about this the wrong way? I know that
> reading/writing code in a language is the best way to
> learn it, but (for example) I've spent about 3 hours total
> staring at one example from the book (3.12, page 52 for
> those who are interested), and it seriously has me
> baffled.
I hear that it is common for programmers to report that
Graham's book goes at too fast a pace and is consequently
too difficult. So a slower paced book may be
indicated. Perhaps "A Gentle Introduction To Symbolic
Computation"
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/dst/www/LispBook/
My vote goes for an alternative - that programmers from a C
background are used to the edit-compile-run cycle being
relatively slow, and so adopt a learning style based
everything being explained in the book, to avoid wasting
time having to try stuff out. But the Read-Eval-Print-Loop
is a wonderful learning environment. It lets you try out
fragments of programs. In Lisp, the Hello World program is
13 characters
"Hello World"
So learning by playing at the REPL goes faster than studying
a fat book and trying to remember it all. The REPL is
mightier than the textbook.
There are six versions of the shortest path problem. In
order of increasing difficulty
1)depth first enumerate and eyball
2)depth first found/not found
3)depth first return actual path
4)breadth first enumerate and eyeball
5)breadth first found/not found
6)breadth first return acutal path
Graham plunges straight into number 6. Rather than trying to
follow at once and getting badly stuck, play at the REPL,
working your way up. Figure 3.12 is hard because breadth
first search is hard computer science. But you are trying,
in the first instance, to learn the language, not computer
science, so be willing to shrug and move on, and come back
to breadth first search later.
Alan Crowe
Edinburgh
Scotland
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
>
> My vote goes for an alternative - that programmers from a C
> background are used to the edit-compile-run cycle being
> relatively slow, and so adopt a learning style based
> everything being explained in the book, to avoid wasting
> time having to try stuff out. But the Read-Eval-Print-Loop
> is a wonderful learning environment. It lets you try out
> fragments of programs. In Lisp, the Hello World program is
> 13 characters
>
> "Hello World"
That's one thing I remember from my first attempt at learning Lisp:
When does he get to the "Hello world"-example! :-)
I found this quite useful howto long time ago; unfortunately is is
out of date:
http://ww.telent.net/lisp/howto.html
An introduction covering how to work with the REPL, SLIME/ILISP,
ASDF, the Hyperspec etc. wold probably be useful.
--
We tend to meet any new situation by reorganising; and a wonderful method
it can be for creating the illusion of progress while producing confusion,
inefficiency and demoralisation. -- Gaius Petronius, 60 AD
From: ··········@YahooGroups.Com
Subject: Re: Some advice for a lisp newb
Date:
Message-ID: <REM-2004mar14-003@Yahoo.Com>
> From: Alan Crowe <····@cawtech.freeserve.co.uk>
> In Lisp, the Hello World program is 13 characters
> "Hello World"
Not quite correct. Firstly, it prints with the quotes still around it,
which is not what the Hello World! program is supposed to do. Second,
it doesn't compile a program or store it by name which can later be
called up to run again without having to re-type the source code again.
Of course you can cheat by typing * to retrieve the most recent value,
but that's not the same as having a program with a permanent name, and
that doesn't actually run the program again at all.
In C and other similar languages, you have to go the whole route of
putting the program text into a source file, compiling, linking, and
running. In LISP you can take baby steps to that point, but still to
really have a Hello World program, not just a value you can retrieve
for a brief time, you have to eventually go all the way.
So in LISP, the baby steps might be:
REP> "Hello World!"
"Hello World!"
;Oops, quotes around it, wrong output, fixing that.
REP> (princ "Hello World!")
Hello World!
"Hello World!"
;Oops, correct output, but then output with quotes also, fixing that.
REP> (progn (princ "Hello World!") (values))
Hello World!
;Success!! Alternately:
REP> (progn (format t "Hello World!~%") (values))
Hello World!
;Now to incorporate that into a globally defined function:
REP> (defun h () (progn (format t "Hello World!~%") (values)))
H
REP> (h)
Hello World!
REP> (cons 1 2)
(1 . 2)
REP> (h)
Hello World!
;Success, you can call it as many times as you want, doing other things
; inbetween and it still remembers the program.
;Now to make a file that does that, i.e. type the filename from the
; shell it'll start up LISP and load that little program and run it and
; exit back to shell ... easier said than done...
Shell> cat > h
#! /bin/sh
/usr/local/bin/lisp -eval '(progn (format t "Hello World!~%") (quit))'
^D
Shell> chmod +x h
Shell> ./h
Hello World!
;Success!! Callable from the shell any time I want to run it again!
;But I suppose that's cheating because even though LISP does the
; printing, the text to be printed is remembered by the shell script.
;So now I'll put the actual stuff into a LISP source file...
Shell> cat > h.lisp
(format t "Hello World!~%")
^D
Shell> cat > h
#! /bin/sh
/usr/local/bin/lisp -eval '(progn (load "h.lisp" :verbose nil) (quit))'
^D
Shell> chmod +x h
Shell> ./h
Hello World!
Anyway, in LISP there are lots of variants of the basic Hello World!
idea, and a beginner can try them all I suppose, and then develop
"real" LISP software using the REP but then "install" them using that
last method. By the way, I have a CGI version here:
http://www.rawbw.com/~rem/cgi-bin/h-cmucl.cgi
But that's the cheat way, where the sh script contains the lisp source.
OK, I've fixed it now to load the h.lisp file which has the lisp source.
(See also, in the same place: h-java.cgi h-perl.cgi h-sh.cgi)
The files can be viewed (as .txt files) in this directory:
http://www.rawbw.com/~rem/HelloWorld/
Compare the lisp and java for example, both using the same method
(source in separate file, sh script to start interpretor then load file
and run it).
On the other hand, compare perl and sh, both directly supported by the
CGI server so all the code is inline.
(In case somebody finds my old article via Google Groups:)
> From: ··········@YahooGroups.Com
> The files can be viewed (as .txt files) in this directory:
> http://www.rawbw.com/~rem/HelloWorld/
Today I created something better:
http://www.rawbw.com/~rem/hellos.html
so the HelloWorld directory is now depricated.
,
From: ··········@YahooGroups.Com
Subject: Re: Some advice for a lisp newb
Date:
Message-ID: <REM-2004may16-001@Yahoo.Com>
> From: Alan Crowe <····@cawtech.freeserve.co.uk>
> Notice that he does not use free variables. Nothing happens to END
> and NET. They are just passed on unchanged to where they are needed.
> So they could be global variables, which would get them out of the
> parameter lists so one could focus attention on the parameter that is
> different from call to call. ... END and NET are not very catchy
> names. This is a search problem, call them NEEDLE and HAYSTACK.
The problem is that if you use any global variable with the same name
anywhere else in the same "core image", the two might step on each
other. To avoid passing unchanged parameters at every level, but to
avoid using global variables, we can take advantage of lexical scope
and closures to create shared private static variables like this:
(let ((needle) (haystack))
(defun shortest-path (start end net)
(setq needle end) (setq haystack net)
(bfs (list (list start))))
(defun bfs (queue)
(if (null queue)
nil
(let ((path (car queue)))
(let ((node (car path)))
(if (eql node needle)
(reverse path)
(bfs (append (cdr queue)
(new-paths path node))))))))
(defun new-paths (path node)
(mapcar #'(lambda (n)
(cons n path))
(cdr (assoc node haystack))))
(Note: I merely transformed what you posted, didn't check for mistakes.)
In Figure 3.12, the code states that the shortest path from a start node to
an end node in a network of nodes is found by performing a breadth-first
search (bfs) for the end node.
A bfs needs to know the end node for which it is searching, a queue
containing the current starting node, and the network which is being
searched. If the queue is empty, there is no current starting node because
the search has exhausted all paths. There is no path from the start node to
the end node. Bfs returns nil. Otherwise, there is a starting node. Bfs
attemps to build a path to the end node. The starting point for this path is
the first entry in the queue.
I need to digress and explain the structure of the queue. The queue is a
list of lists. The first entry, and every entry, in the queue is a list. Bfs
readies itself to search a path, which is the first entry in the queue. This
path is a list of nodes. The first entry in the path is a node. Bfs now has
a current path and a current node in that path.
If the current node is the goal, or end, node, bfs returns the path as the
solution to the search. Because the path was built up in reverse order, a
common idiom, used for efficiency, which can be explained separately, the
path is reversed before it is returned so that the returned path is in
start-to-end sequence.
If the current node is not the goal, or end, node, then another bfs search
will be performed. This new bfs search uses the same end node as the current
bfs search and the same network of nodes to be searched as the current bfs
search. The middle parameter, the queue of nodes searched so far, is
different for the new bfs search than the queue used in the current bfs
search.
The new queue for the new bfs search is constructed by appending the "rest"
of the current queue to the result of the function "new-paths" called with
the current path, current node, and current network of nodes. I will explain
new-paths separately from the rest of bfs.
As I said before, bfs is reinvoked with the same end goal node and the same
network but with a new queue. The new queue is "almost" the same as the old
queue but not quite the same. The new queue is missing the first entry of
the old queue, which we just searched, and the new queue includes any
new-paths that can be found when examining the current node. At some point,
either the end node will be found or the search will exhaust any possible
new-paths. There will be no more new-paths yet each recursion, or repeated
execution, through bfs will shorten the queue because only the rest of the
queue -- (cdr queue) -- is passed on each subsequent call to bfs. Therefore,
bfs eventually will either find the end node or terminate after determining
that there is no path to the end node.
How are new-paths found? The new-paths function accepts the current path,
the current node, and the network of nodes being searched. New-paths uses
mapcar, which maps a function over a list. The function is called once for
each member of the list. The results of each function call are collected
into a list, which is returned as the result of the mapcar. The mapcar's
result is returned as the result of new-paths.
The broad structure, then, is that a function will be called for every
member of a list and the results of the function will be put into a list
which will be returned as the result of new-paths. We need to understand the
function called for each member of the list and we need to understand what
is in the list whose members are passed to the function.
The function called for each member of the list accepts "n" and returns
(cons n path). Path is a list which was given to new-paths as a parameter.
The form "(cons X list)", in general, returns a list with X as the first
member of the list and the old list as all the other members. (Look on page
356 for information on append and cons. Decide what the differences are
between (append X list) and (cons X list), if there are any differences, and
when one or the other should be used.) We already know that, in this
example, a path is a list of nodes, so it is reasonable to guess that n is a
node. The lambda function used in the mapcar returns (cons n path) and the
mapcar accepts that returned result, saving it in a list, which will be
returned as the result of new-paths.
We have mapcar mapping a function over a list. What is the list? The code
gives it as (cdr (assoc node net)). On page 51 see that "(N)etworks are
represented as assoc-lists with elements of the form (node . neighbors)".
Assoc returns the entire (node . neighbors) form for the first entry in the
assoc list for which the node in the call to assoc matches the car of the
assoc-list entry. Assoc returned a (node . neighbors) structure in which the
node tests as equal to the node specified in the call to assoc. Assoc
returned (node . neighbors) but all we want is the neighbors, so we use (cdr
(assoc node net)).
New-paths simply returns a list of all the neighbors of a given node.
To summarize: The shortest-path from a start node to an end node in a
network of nodes is found via breadth-first search (bfs), which is given the
end, or goal, node, a list containing a list containing the start node, and
the network of nodes to be searched. Bfs returns nil if there is no path
from the start node to the end node. If there is at least one node remaining
to search, bfs examines the first path in the current queue of paths. Each
path is a list of nodes. Bfs looks at the first node in the current path. If
that node is the end node, bfs returns the current path because the current
path led bfs to the end node. If that node is not the end node, bfs is
called again using the paths not yet searched followed by a new path
consisting of the neighbors of the current node.
"Brett Kelly" <·······@inkedmn.com> wrote in message
··································@inkedmn.com...
> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
> the first couple of chapters and I have to say that, by and large, I'm
> lost.
>
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
> the wrong book? Am I going about this the wrong way? I know that
> reading/writing code in a language is the best way to learn it, but (for
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
>
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
>
> Any suggestions?
>
> Thanks in advance!!
Brett Kelly wrote:
> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
> the first couple of chapters and I have to say that, by and large, I'm
> lost.
>
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
> the wrong book? Am I going about this the wrong way?
Yes, it's normal, especially for people who've spent a long time
programming in other more mainstream languages. Graham's book is
allegedly pretty good, though I haven't read it. You could try
looking at either David Lamkins's book "Successful Lisp", or Peter
Seibel's book "Practical Common Lisp", both available online in
draft versions; you might find that one or other of those fits
your brain better than Graham's book.
> I know that
> reading/writing code in a language is the best way to learn it, but (for
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
It might be worth going back a few pages and looking at earlier
examples until you're sure you have them thoroughly understood,
I suppose. I don't have a copy of Graham's book, so I can't help
with the particular example you mention. Can you say what it is
that's confusing you, or is the whole thing just overloading your
brain with a general sense of bafflement? :-)
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
I think you should expect that. If you could just do it easily
then it's hard to see how it could be so very enlightening :-).
> Any suggestions?
Um, keep at it? Ask some more specific questions here, if you can
pin down what's bothering you?
--
Gareth McCaughan
.sig under construc
Thanks for the advice, I've glanced at Lamkins' book once before, but the
overwhelming majority of lispers i know recommended Graham. But I'll
definitely check them out.
As far as re-reading the preceding pages, I've done it many times :) It's
not that I don't get what car and cdr are, or what a cons is, that much
makes sense. He just seems to introduce new things quickly and (at times)
without explaining them.
But I'm nowhere near giving up, so I'll keep you posted :)
Thanks again.
On Sat, 13 Mar 2004 21:19:25 +0000, Gareth McCaughan wrote:
> Brett Kelly wrote:
>
>> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
>> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
>> the first couple of chapters and I have to say that, by and large, I'm
>> lost.
>>
>> Now, I consider myself to be a fairly intelligent guy, and I'm able to
>> pick up other (imperative) languages fairly quickly, but Lisp is just
>> giving my brain a serious run for its money. Is this normal? Am I reading
>> the wrong book? Am I going about this the wrong way?
>
> Yes, it's normal, especially for people who've spent a long time
> programming in other more mainstream languages. Graham's book is
> allegedly pretty good, though I haven't read it. You could try
> looking at either David Lamkins's book "Successful Lisp", or Peter
> Seibel's book "Practical Common Lisp", both available online in
> draft versions; you might find that one or other of those fits
> your brain better than Graham's book.
>
>> I know that
>> reading/writing code in a language is the best way to learn it, but (for
>> example) I've spent about 3 hours total staring at one example from the
>> book (3.12, page 52 for those who are interested), and it seriously has me
>> baffled.
>
> It might be worth going back a few pages and looking at earlier
> examples until you're sure you have them thoroughly understood,
> I suppose. I don't have a copy of Graham's book, so I can't help
> with the particular example you mention. Can you say what it is
> that's confusing you, or is the whole thing just overloading your
> brain with a general sense of bafflement? :-)
>
>> I've been told (and read on several different sites) that learning Lisp
>> will change the way you look at programming. I'm excited about this
>> "enlightenment", but frustrated at the fact that it's not coming very
>> easily to me...
>
> I think you should expect that. If you could just do it easily
> then it's hard to see how it could be so very enlightening :-).
>
>> Any suggestions?
>
> Um, keep at it? Ask some more specific questions here, if you can
> pin down what's bothering you?
+ Brett Kelly <·······@inkedmn.com>:
| the overwhelming majority of lispers i know recommended Graham.
It may be better at a later point on your learning curve. I found it
excellent, but then I already had a pretty good idea what Lisp is
about before I started it. I had the great luxury of being able to
pick up Lisp little by little, over a great many years. It's a
language that grows on you, not a love-on-first-sight language.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Brett Kelly <·······@inkedmn.com>:
>
> | the overwhelming majority of lispers i know recommended Graham.
>
> It may be better at a later point on your learning curve. I found it
> excellent, but then I already had a pretty good idea what Lisp is
> about before I started it. I had the great luxury of being able to
> pick up Lisp little by little, over a great many years. It's a
> language that grows on you, not a love-on-first-sight language.
My first impression of Lisp was not a good one. Everything about the
language seemed weird to me. It was bewildering and alien. Who
would want to program in such a language?
As time passed, I continued to hear things about Lisp. I still
didn't get it though.
Then one day I was thinking about writing a program. This is a
program I have yet to write. Still. After more than six years of
thinking about it. Anyway, this program needs to have a built in
scripting language. I don't want to spend a bunch of time and energy
just to write a parser and all the other stuff you need for a
scripting language. I also don't think I am able to design a good
language.
Suddenly I started to see something appealing about Lisp. I was
thinking about Scheme for implementation reasons. There was another
feature I wanted. I wanted to blur the lines between code and data.
It should be possible to introduce new objects into the system that
know how to interact with the system. The system should then be able
to interact with these new objects.
An idea began to gell in my mind that a file could contain both code
and data (I know, duh!) in the form of s-expressions. Easy to parse,
easy to manipulate. Mind you, I am a bit lazy at times. Why not use
a language that already knows how to deal with s-expressions?
There is also another program out there that is a rather huge
inspiration to me. That program is Emacs. Emacs Lisp is no Common
Lisp, but it makes the editor about as extensible as any program can
be. You might say that Emacs is its own little OS.
So now I am going through the trials of learning Lisp. I still don't
get it, but I am seeing something glowing on the horizon. I am
beginning to get used to the different way of programming vs C or
Java. It is even different than Perl or Python. Scripting languages
can be pretty interactive, but I don't think they quite match Lisp.
Lisp is a language that seems to fit my organic programming style.
This is a style that does not grow well with C or Java. It works
better with Perl (and probably Python or Ruby or whatever VHLL
scripting language). However, I think it just may work best with
Lisp. So rather than having to bend my mind to the language, the
language bends itself to me.
I don't have a CS degree of any sort so I find that I am learning a
few other things about programming in general while I am learning
Lisp. So far, it is an interesting and very challenging ride.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
From: Joe Marshall
Subject: Re: Some advice for a lisp newb
Date:
Message-ID: <oeqzx7ma.fsf@comcast.net>
David Steuber <·············@verizon.net> writes:
> An idea began to gell in my mind that a file could contain both code
> and data (I know, duh!) in the form of s-expressions. Easy to parse,
> easy to manipulate. Mind you, I am a bit lazy at times. Why not use
> a language that already knows how to deal with s-expressions?
Laziness is very important for a computer scientist. Some of them
work very hard at to avoid doing unnecessary work.
--
~jrm
David Steuber wrote:
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
>
>>+ Brett Kelly <·······@inkedmn.com>:
>>
>>| the overwhelming majority of lispers i know recommended Graham.
>>
>>It may be better at a later point on your learning curve. I found it
>>excellent, but then I already had a pretty good idea what Lisp is
>>about before I started it. I had the great luxury of being able to
>>pick up Lisp little by little, over a great many years. It's a
>>language that grows on you, not a love-on-first-sight language.
>
>
> My first impression of Lisp was not a good one. Everything about the
> language seemed weird to me. It was bewildering and alien. Who
> would want to program in such a language?
>
> As time passed, I continued to hear things about Lisp. I still
> didn't get it though.
>
> Then one day I was thinking about writing a program. This is a
> program I have yet to write. Still. After more than six years of
> thinking about it. Anyway, this program needs to have a built in
> scripting language. I don't want to spend a bunch of time and energy
> just to write a parser and all the other stuff you need for a
> scripting language. I also don't think I am able to design a good
> language.
>
> Suddenly I started to see something appealing about Lisp.
<snip great "Road to Lisp">
I had a similar experience with a big commercial app I was developing. I
knew it was going to need an internal language, but in my case I was
held back by the anticipated horror with which my employer would greet
the idea of using Lisp. But Lisp just forced itself onto the project,
too damn appropriate for the task to be ignored.
Can you hang some dates on those milestones, roughly? That first
negative reaction, the subsequent decision to reconsider, etc.
I would harrass you into adding this story to my survey (see sig), but
the survey is broken and anyway, I think it has outlived its purpose.
The question I wanted answered was, How did you find your way to a dead
language? But now comp.lang.lisp has more rug rats crawling around than
a day care center, and, well, it seems Lisp ain't dead any more. And
when Peter's book comes out...oh, my. I should be starting work on
Practical Cello.
[Erann, phone home.]
:)
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Can you hang some dates on those milestones, roughly? That first
> negative reaction, the subsequent decision to reconsider, etc.
That would all be rather difficult. I'm not sure that dates really
matter much.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
Harald Hanche-Olsen wrote:
> + Brett Kelly <·······@inkedmn.com>:
>
> | the overwhelming majority of lispers i know recommended Graham.
>
> It may be better at a later point on your learning curve. I found it
> excellent, but then I already had a pretty good idea what Lisp is
> about before I started it. I had the great luxury of being able to
> pick up Lisp little by little, over a great many years. It's a
> language that grows on you, not a love-on-first-sight language.
>
Speak for yourself--some of us did fall in love with Lisp from our very
first (+ 2 3)! :)
David Sletten wrote:
> Harald Hanche-Olsen wrote:
>
>> + Brett Kelly <·······@inkedmn.com>:
>>
>> | the overwhelming majority of lispers i know recommended Graham.
>>
>> It may be better at a later point on your learning curve. I found it
>> excellent, but then I already had a pretty good idea what Lisp is
>> about before I started it. I had the great luxury of being able to
>> pick up Lisp little by little, over a great many years. It's a
>> language that grows on you, not a love-on-first-sight language.
>>
>
> Speak for yourself--some of us did fall in love with Lisp from our very
> first (+ 2 3)! :)
We are getting surprising mileage variation on this. AFAIAC:
(easy-as '(a b c) '(1 2 3) '(do re mi))
That's what love means to me.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Brett Kelly <·······@inkedmn.com> writes:
> Thanks for the advice, I've glanced at Lamkins' book once before, but the
> overwhelming majority of lispers i know recommended Graham. But I'll
Lamkins' book is less known that Graham's.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <·····························@inkedmn.com>,
Brett Kelly <·······@inkedmn.com> wrote:
> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
> the first couple of chapters and I have to say that, by and large, I'm
> lost.
>
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
> the wrong book? Am I going about this the wrong way? I know that
> reading/writing code in a language is the best way to learn it, but (for
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
>
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
>
> Any suggestions?
>
> Thanks in advance!!
The ALU site has some educational resources.
I'm not sure that Graham's book(s) are good for LEARNING
Lisp. Winston/Horn's "Lisp, 3rd Edition" seems to me better
for learning. Or some of the online available books.
I like the style of Winston/Horn, though it is a bit old.
A classic, where you really can learn a lot from, is
Peter Norvig's "Paradigms of Artificial Intelligence
Programming". Don't let the title confuse you - this is
probably one of the best books on programming with Lisp.
He develops code and explains how to improve it. So
the book contains a good part of reasoning why he is
writing the code in the way he does. Often you see
only smaller examples and not much about the thought
process of an advanced programmer. Norvig's book is
different. I would not hesitate to recommend people
to buy this book (even though it is a bit expensive -
but it is a large book ;-)).
For some in-depth CLOS you would have to consult other
books.
For learning Lisp you might need to unlearn some old habits.
Lisp is often best used interactively. For many experiments
you just need a Listener (a read-eval-print-loop) and
an editor. If you read a book either type the examples
yourself and experiment with them or use some of
the online archives where you can find code for the books.
The code for Norvig's book is available online and
is quite complete, so you can use it in your own
experiments (like experimenting with user interfaces to
some of the stuff).
Another thing to use would be a good reference for the
basic Lisp constructs. The Hyperspec is kind of an
HTML-version of the ANSI CL spec. So it is sometimes
not really useful as a beginners reference. Sometimes
the Lisp systems have additional reference material
(like MCL's light-weight online help). But, when
in doubt, you have to consult the HyperSpec (or
a comparable source of authority) for getting
the definitive answer (if there is one ;-) ).
http://www.norvig.com/paip.html
Code:
http://www.norvig.com/paip/README.html
On 2004-03-14 10:35:02, Rainer Joswig wrote:
> Norvig's book is
> different. I would not hesitate to recommend people
> to buy this book (even though it is a bit expensive -
> but it is a large book ;-)).
And it's a bit boring when you're not interested into AI.
On Sun, 14 Mar 2004 12:35:11 +0100, Stefan Scholl <······@no-spoon.de> wrote:
> And it's a bit boring when you're not interested into AI.
I'm not interested in AI and I didn't think PAIP was boring. To the
contrary, for me this was one of the most entertaining books about
programming languages I've ever read.
Edi.
Edi Weitz <···@agharta.de> wrote in message news:<··············@bird.agharta.de>...
> I'm not interested in AI and I didn't think PAIP was boring. To the
> contrary, for me this was one of the most entertaining books about
> programming languages I've ever read.
>
> Edi.
Strangely enough, that AIMA book Norvig wrote with the other guy was
actually the best intro to certain concepts. Such as the
breadth-first search someone mentioned earlier. I suspect it has to
do with AI being about making machines do whatever they can.
The "intelligence" part seems to be marketing/obfuscation. Therefore
AI would seem to encompass anything you'd do with software.
Brett Kelly <·······@inkedmn.com> writes:
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
This is not unusual. Lisp is an advanced language with a long--almost
half a century--tradition. Since you are apparently learning it for
your own interest, and you do not have work-related schedules related
to it, you can take all the time you need.
[about Graham's "ANSI Common Lisp"]
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
Any specific problems? You may begin by telling what you understand of
the example, and what you don't. Maybe you are not able to visualize
the data structures on which the functions operate.
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
You bet :-)
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
>
> Any suggestions?
You may ask specific questions about the things you are stuck with.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Joe Marshall
Subject: Re: Some advice for a lisp newb
Date:
Message-ID: <hdwqxxbv.fsf@comcast.net>
Brett Kelly <·······@inkedmn.com> writes:
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
> the wrong book? Am I going about this the wrong way? I know that
> reading/writing code in a language is the best way to learn it, but (for
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
That's a pretty hairy example, especially for someone that is just
starting.
The `queue' variable holds the `frontier' of the search, but each
entry also holds the path from the root to the frontier.
Additionally, each entry is stored in reverse order because it is more
convenient.
At each step, you look at the head of the queue and see if it
terminates at the desired node (since the queue is in reverse order,
you look at the first element). If it does terminate, return the path
(ensure that you reverse it before returning it). If it doesn't
terminate, add several entries to the queue. Each entry will contain
the reverse path so far and one of the children of the current node.
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
It can take a couple of weeks for the ideas to gel. Don't worry, it
will suddenly dawn on you. Just be patient.
--
~jrm
"Brett Kelly" <·······@inkedmn.com> wrote in message
··································@inkedmn.com...
> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
> the first couple of chapters and I have to say that, by and large, I'm
> lost.
>
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
> the wrong book? Am I going about this the wrong way? I know that
> reading/writing code in a language is the best way to learn it, but (for
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
>
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
Read it. Skip stuff that makes your eyes water and push on. If you find that
you're completely lost, start over.
Seriously.
There is a lot of vocabulary and old concepts presented in a new way to
grok.
The biggest problem is that you're going in with all of this experience and
may be skipping over things "that you already know".
car, cdr, let, lambda. Those are the biggies.
Regards,
Will Hartung
(·····@msoft.com)
Clinging to sanity, "Will Hartung" <·····@msoft.com> mumbled into her beard:
> "Brett Kelly" <·······@inkedmn.com> wrote in message
> ··································@inkedmn.com...
>> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
>> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
>> the first couple of chapters and I have to say that, by and large, I'm
>> lost.
>>
>> Now, I consider myself to be a fairly intelligent guy, and I'm able
>> to pick up other (imperative) languages fairly quickly, but Lisp is
>> just giving my brain a serious run for its money. Is this normal?
>> Am I reading the wrong book? Am I going about this the wrong way?
>> I know that reading/writing code in a language is the best way to
>> learn it, but (for example) I've spent about 3 hours total staring
>> at one example from the book (3.12, page 52 for those who are
>> interested), and it seriously has me baffled.
>>
>> I've been told (and read on several different sites) that learning
>> Lisp will change the way you look at programming. I'm excited
>> about this "enlightenment", but frustrated at the fact that it's
>> not coming very easily to me...
>
> Read it. Skip stuff that makes your eyes water and push on. If you
> find that you're completely lost, start over.
>
> Seriously.
>
> There is a lot of vocabulary and old concepts presented in a new way
> to grok.
>
> The biggest problem is that you're going in with all of this
> experience and may be skipping over things "that you already know".
>
> car, cdr, let, lambda. Those are the biggies.
Well, code that is filled with car and cdr and other "list
manipulation" deteriorata represents a good example of stuff that
would be expected to "make your eyes water."
Lisp code that is written well doesn't involve "fighting" with list
ops; you should just need to use them when they are needed.
Another other really major thing that takes some "grokking" is the notion
of "places."
Consider the following setf...
(setf raw-variable 3.141
(cdr somelist) 23
(gethash key *hashtable*) 171
(id someobject) 27314132 ;;; someobject is a CLOS object
(name someobject) "silly name"
(aref *myarray* 2 3) (sin 4.5))
Allowing assigning values to 'places' is one of the really clever
things that Common Lisp does; it's not all that hard to grasp, but it
takes a while to figure out just how useful it is :-).
--
(format nil ···@~S" "cbbrowne" "ntlug.org")
http://www.ntlug.org/~cbbrowne/lisp.html
"I don't plan to maintain it, just to install it." -- Richard M. Stallman
"Christopher Browne" <········@acm.org> wrote in message
····················@ID-125932.news.uni-berlin.de...
> Clinging to sanity, "Will Hartung" <·····@msoft.com> mumbled into her
beard:
> > Read it. Skip stuff that makes your eyes water and push on. If you
> > find that you're completely lost, start over.
> >
> > Seriously.
> >
> > There is a lot of vocabulary and old concepts presented in a new way
> > to grok.
> >
> > The biggest problem is that you're going in with all of this
> > experience and may be skipping over things "that you already know".
> >
> > car, cdr, let, lambda. Those are the biggies.
>
> Well, code that is filled with car and cdr and other "list
> manipulation" deteriorata represents a good example of stuff that
> would be expected to "make your eyes water."
>
> Lisp code that is written well doesn't involve "fighting" with list
> ops; you should just need to use them when they are needed.
Yes, but a lot of text books code does not do this, relying on ye olde
car/cdr, etc. It's the classic car/cdr vs first/rest argument, and because
the List is such an intrinsic type in Lisp.
But if you get bogged down in these things, it can all come to a screeching
halt, whereas if you pass them by, the concept may come up again in a
context that makes it more clear for the reader. Eventually you either get
through it and understand it, or the text relies on these concepts so much
that you are completely stuck. At that point, just start over. With new
found knowledge, a lot of this stuff may make more sense on the second pass.
> Another other really major thing that takes some "grokking" is the notion
> of "places."
>
> Consider the following setf...
>
> (setf raw-variable 3.141
> (cdr somelist) 23
> (gethash key *hashtable*) 171
> (id someobject) 27314132 ;;; someobject is a CLOS object
> (name someobject) "silly name"
> (aref *myarray* 2 3) (sin 4.5))
>
> Allowing assigning values to 'places' is one of the really clever
> things that Common Lisp does; it's not all that hard to grasp, but it
> takes a while to figure out just how useful it is :-).
The detail to note there is that "place" is a capability of the SETF macro,
so it's SETF that's doing all of the magic. And you can't pass a "place" to
a function, it's not a first class concept.
But, setf is so dominant now, that set and setq are pretty much non-existent
from a usage point of view. (With reason, of course).
But when you introduce setf as:
(setf a 1)
(setf b #\b)
(setf c "C")
(setf (aref d 1) #xD)
You just say "oh, SETF is just assignment", without understanding the
details. That's both a good and bad thing.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
>
> The detail to note there is that "place" is a capability of the SETF macro,
> so it's SETF that's doing all of the magic. And you can't pass a "place" to
> a function, it's not a first class concept.
Aesthetically, this has always bugged me. If something is a good first
argument for a mutator, then it seems to me that it has to be returning
a location rather than a value - or some kind of compound datum that
includes both a location and a value leaving the continuation to decide
which it will use.
While I'm aware that what's really happening is that SETF is sucking up
the reference expression and rearranging its arguments into a mutator
expression, I'm just uncomfortable that the reference expression here
does not mean the same thing it means if it appears outside the macro.
It seems to mislead the programmer, to give false impressions about
what the reference expression does.
> But when you introduce setf as:
> (setf a 1)
> (setf b #\b)
> (setf c "C")
> (setf (aref d 1) #xD)
>
> You just say "oh, SETF is just assignment", without understanding the
> details. That's both a good and bad thing.
To me, it seems bad. This makes SETF look like a procedure which takes a
location and a value; ergo, the newbie is led to believe that variable
references and array references give locations instead of values, and that
SETF is a procedure. These notions are "false friends" - ideas that
s/he will later have to unlearn.
Bear
Ray Dillinger <····@sonic.net> writes:
> This makes SETF look like a procedure which takes a location and a
> value; ergo, the newbie is led to believe that variable references
> and array references give locations instead of values, and that SETF
> is a procedure.
This one still frustrates me. Having programmed in C and C++ for a
while, I'm used to being able to use (non-const) pointers and, more
appropriately, (non-const) references as lvalue "places" to both read
from /and/ write to. Swapping two "places" exemplifies the difference.
In C++, to swap two array elements, we can use something like this:
(This is the typical swap function from the Standard Library, which
may be specialized for types that can provide a more efficient swap
than this copy-assign-assign version.)
,----
| template <typename T>
| void swap(T& a, T& b)
| {
| const T tmp = a;
| a = b;
| b = tmp;
| }
|
| int array[] = { 0, 1 };
| swap( array[0], array[1] );
`----
Now in CL, I wrote a similar but less general swap function this way,
specifically for vectors:
,----
| (defun swap-vector-elements (v pos1 pos2)
| (let ((e1 (aref v pos1)))
| (setf (aref v pos1) (aref v pos2))
| (setf (aref v pos2) e1))
| v)
|
| (let ((array (vector 0 1)))
| (swap-vector-elements array 0 1))
`----
It /looks/ like we have to access both index "pos1" and index "pos2"
in vector "v" twice, whereas the C++ version only manifests that
access once. (Or, rather, the address of each element is computed
once, giving us a "place" ready for immediate read or write.)
I can't see a way to pass a particular vector element "place" to a
function. We have rotatef to make the above function less verbose, but
it only helps for these swap/rotate situations. Maybe it takes
defining a struct that binds both the vector and an index, and
specializing a generic swap method on such a structure. Or maybe using
"places" like this just isn't idiomatic in CL, and I need to unlearn
this desire.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
"Steven E. Harris" <········@raytheon.com> writes:
> Ray Dillinger <····@sonic.net> writes:
>
>> This makes SETF look like a procedure which takes a location and a
>> value; ergo, the newbie is led to believe that variable references
>> and array references give locations instead of values, and that SETF
>> is a procedure.
>
> This one still frustrates me. Having programmed in C and C++ for a
> while, I'm used to being able to use (non-const) pointers and, more
> appropriately, (non-const) references as lvalue "places" to both read
> from /and/ write to. Swapping two "places" exemplifies the difference.
>
> In C++, to swap two array elements, we can use something like this:
> (This is the typical swap function from the Standard Library, which
> may be specialized for types that can provide a more efficient swap
> than this copy-assign-assign version.)
>
> ,----
> | template <typename T>
> | void swap(T& a, T& b)
> | {
> | const T tmp = a;
> | a = b;
> | b = tmp;
> | }
> |
> | int array[] = { 0, 1 };
> | swap( array[0], array[1] );
> `----
>
> Now in CL, I wrote a similar but less general swap function this way,
> specifically for vectors:
>
> ,----
> | (defun swap-vector-elements (v pos1 pos2)
> | (let ((e1 (aref v pos1)))
> | (setf (aref v pos1) (aref v pos2))
> | (setf (aref v pos2) e1))
> | v)
> |
> | (let ((array (vector 0 1)))
> | (swap-vector-elements array 0 1))
> `----
>
> It /looks/ like we have to access both index "pos1" and index "pos2"
> in vector "v" twice, whereas the C++ version only manifests that
> access once. (Or, rather, the address of each element is computed
> once, giving us a "place" ready for immediate read or write.)
>
> I can't see a way to pass a particular vector element "place" to a
> function. We have rotatef to make the above function less verbose,
> but it only helps for these swap/rotate situations. Maybe it takes
> defining a struct that binds both the vector and an index, and
> specializing a generic swap method on such a structure. Or maybe
> using "places" like this just isn't idiomatic in CL, and I need to
> unlearn this desire.
Hmmm. What are you actually trying to do. If you used ROTATEF in the
example you gave it would end pretty much like the C++ version. If you
really want to go nuts, check out GET-SETF-EXPANSION.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> What are you actually trying to do.
I've been writing some programs to generate permutations and
combinations, working with vectors as storage. These algorithms
involve a lot of stepping array positions and swapping values --
operations well-suited to "pointer-like" primitives.
> If you used ROTATEF in the example you gave it would end pretty much
> like the C++ version.
Yes, syntactically, but the macro expansion revealed that it set up
/two/ temporary bindings for the overlapping elements when I can see
that only one is necessary (as is the case with any single-step
rotation).� That seemed superfluous; rotatef was doing more than I
needed.
CL-USER> (macroexpand '(rotatef (aref v 0) (aref v 1)))
(LET* ((#:G1071 V) (#:G1072 0) (#:G1074 V) (#:G1075 1))
(MULTIPLE-VALUE-BIND (#:G1076) (AREF #:G1071 #:G1072)
(MULTIPLE-VALUE-BIND (#:G1073) (AREF #:G1074 #:G1075)
(SYSTEM::STORE #:G1071 #:G1072 #:G1073)
(SYSTEM::STORE #:G1074 #:G1075 #:G1076)))
NIL)
T
That both AREF and SYSTEM::STORE require two arguments to access a
single variable indicates that some intermediate computation must be
done to find that variable -- such as adding some multiple of the
index to the base address of the array.� That computation gets done
twice above -- once for each read, and once for each write. It would
be nice if one could cache that computation for several later reads
and writes, giving something more like:
(let ((place1 (place (aref v 0)))
(place2 (place (aref v 1))))
(let ((tmp place1))
(setf place1 place2)
(setf place2 tmp)))
It's sort of like with-slots, but I understand that the with-slots
bindings are in a lexical environment, and one can't pass a slot
"place" around as an object.
> If you really want to go nuts, check out GET-SETF-EXPANSION.
I'll take a look again. Last time I tried, I got a headache.
Footnotes:
� With clisp 2.32.
� In C, that's either (array + index) or perhaps &array[index].
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
On Tue, 16 Mar 2004 15:15:48 -0800, Steven E. Harris wrote:
> Yes, syntactically, but the macro expansion revealed that it set up
> /two/ temporary bindings for the overlapping elements when I can see
> that only one is necessary (as is the case with any single-step
> rotation).
With an even little optimizing compiler they generate the same code.
Processors typically don't have memory-memory moves, the value must be put
in a temporary register anyway. It doesn't matter whether the temporary
came from a source-level variable, or if it was introduced by a compound
expression.
> That both AREF and SYSTEM::STORE require two arguments to access a
> single variable indicates that some intermediate computation must be
> done to find that variable -- such as adding some multiple of the
> index to the base address of the array.
This is more tricky to optimize out. I believe it's feasible only at the
lower level, where the code generator might spot a common subexpression
in an intermediate language. With many garbage collectors source-level
references into the middle of an object would be dangerous: let such
reference live across a garbage collection and bad things can happen.
With a copying garbage collector the object might be moved, with a
non-copying collector it might be freed too early. Usually there is no
need to trace pointers into the middle of objects, it would be more
expensive with only a little gain. Lisp, as most languages, doesn't have
such references at the source level.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Joe Marshall
Subject: Re: Some advice for a lisp newb
Date:
Message-ID: <n06fzhfs.fsf@ccs.neu.edu>
"Steven E. Harris" <········@raytheon.com> writes:
> Ray Dillinger <····@sonic.net> writes:
>
>> This makes SETF look like a procedure which takes a location and a
>> value; ergo, the newbie is led to believe that variable references
>> and array references give locations instead of values, and that SETF
>> is a procedure.
>
> This one still frustrates me. Having programmed in C and C++ for a
> while, I'm used to being able to use (non-const) pointers and, more
> appropriately, (non-const) references as lvalue "places" to both read
> from /and/ write to. Swapping two "places" exemplifies the difference.
The lisp machine had `locatives' which allowed you to do this sort of
thing, but locatives complicate the task of the garbage collector and
the compiler.
Ray Dillinger <····@sonic.net> writes:
> To me, it seems bad. This makes SETF look like a procedure which takes a
> location and a value; ergo, the newbie is led to believe that variable
> references and array references give locations instead of values, and that
> SETF is a procedure. These notions are "false friends" - ideas that
> s/he will later have to unlearn.
But Lisp is full of it.
Special operators, macros, vs. plain function AND parenthesis!
The important point is that there are parenthesis everywhere to delimit
the scopes of each mini-languages (or the scopes of abstraction).
Each operator can be seen as its own mini-language. There are the huge
LOOP and the big FORMAT, and the simple SET, and shades of grey and
colors in between.
On the other hand, you could probably tweak Lisp to do what you want,
and have all function get "places" as arguments, and return "places" as
result.
(defun fact (x) (if (>= 1 x) 1 (* x (fact (1- x)))))
(defun other (y) (if (evenp y) (setf y (/ y 2))) y)
(let ((x))
(setf (other (fact x)) 12)
(assert (= x 4)))
Of course, you'd need to simulate a quantum computer (or implement
prolog) to be able to run:
(let ((x)) (setf (other (fact x)) (+ (* 2 n) 1)))
I just have one question: does it resolve elegantly one domain
problem you have?
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Christopher Browne wrote:
> Clinging to sanity, "Will Hartung" <·····@msoft.com> mumbled into her beard:
>
>>"Brett Kelly" <·······@inkedmn.com> wrote in message
>>··································@inkedmn.com...
>>
>>>I've been told (and read on several different sites) that learning
>>>Lisp will change the way you look at programming. I'm excited
>>>about this "enlightenment", but frustrated at the fact that it's
>>>not coming very easily to me...
>>
>>car, cdr, let, lambda. Those are the biggies.
>
>
> Well, code that is filled with car and cdr and other "list
> manipulation" deteriorata represents a good example of stuff that
> would be expected to "make your eyes water."
True, but I liked the car-cdr recommendation because I took that to mean
"make sure you understand the cons cell". Especially what really goes on
behind the scene of list operations, so that the mystery goes away in re
destructive operations. Without that, one ends up writing incredibly
slow code, either without realizing it or in paranoia over destructive
operations, by forever copying structure.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Christopher Browne <········@acm.org> wrote:
+---------------
| Consider the following setf...
| (setf raw-variable 3.141
| (cdr somelist) 23
| (gethash key *hashtable*) 171
| ... )
|
| Allowing assigning values to 'places' is one of the really clever
| things that Common Lisp does; it's not all that hard to grasp, but it
| takes a while to figure out just how useful it is :-).
+---------------
The idiom that recently won my vote for the "Wow! *Just* what I needed!"
award was:
(incf (gethash key *hashtable* 0))
I have yet to see a neater way to look for duplicates or build histograms...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Brett Kelly <·······@inkedmn.com> writes:
> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
> the first couple of chapters and I have to say that, by and large, I'm
> lost.
(...)
>
> Any suggestions?
>
> Thanks in advance!!
NOTE: Advice from a newbie
ANSI Common Lisp is very terse, IMHO. It impacts you precisely because of that.
I read it (for a first LISP book) and remained lost. But maybe this
had to do with me not being from computer science, and being ignorant
then about basic things such as a ring buffer (and, hmm, I decided to
take classes at the university because of that).
Things cleared up more with Winston's LISP. It starts slowly but digs
into some important concepts. It covers basic lexical scope in a great way.
Object-Oriented Common LISP, by Stephen Slade is another obligatory
introductory book, it covers a *lot* of LISP vocabulary, and has
non-trivial excersises (solved). This is important because LISP is a huge
language, and no other book is so complete in terms of detailed coverage.
On Lisp, which I am beginning now is a book that *everybody*
recommends, but it has to be read after you are more confortable with
[a larger part of] the vocabulary (980 functions, they say). I'm on the first few
chapters, already it threw me into warp speed. You go "Oh! I see...
[something that wasn't clear for a long time]."
Some *very* introductory books were written (e.g., LISP as your first
programming language), but they are out of print. Maybe in a college
library near you (most are non-ANSI). Can be enlightening on
basic data structures done in LISP, though.
I don't know about Sonja Keene's book on CLOS, everybody says it's
good. There's also a French book on CLOS (Objectif CLOS) that I want to buy (see
http://www.eyrolles.com/Informatique/Livre/9782225851209/Livre_Objectif_CLOS.php),
and you might want to check it out too, in case you read French (by
the way, if you're reading this and are aware of LISP books in other
languages that aren't just trabslations, please post - nihongo notwithstanding).
And Practical Common Lisp (http://www.gigamokeys.com/book) is a book that is
coming out great in the sense that it demonstrates how to do everyday
things in LISP, making LISP look as easy as Python or Perl.
On the whole, I estimate you have to read around 2000 pages (spec excluded).
Best regards,
Henry
Henry Lenzi <··········@fuckspam.org> writes:
> On the whole, I estimate you have to read around 2000 pages (spec excluded).
That's not at all scary.
Hey. I typed that with a straight face.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
Brett Kelly wrote:
> I'm a C#/SQL programmer by trade, and I've recently acquired ANSI Common
> Lisp by Paul Graham intending to learn Lisp as a hobby. I've read through
> the first couple of chapters and I have to say that, by and large, I'm
> lost.
>
> Now, I consider myself to be a fairly intelligent guy, and I'm able to
> pick up other (imperative) languages fairly quickly, but Lisp is just
> giving my brain a serious run for its money. Is this normal? Am I reading
> the wrong book? Am I going about this the wrong way? I know that
> reading/writing code in a language is the best way to learn it, but (for
> example) I've spent about 3 hours total staring at one example from the
> book (3.12, page 52 for those who are interested), and it seriously has me
> baffled.
>
> I've been told (and read on several different sites) that learning Lisp
> will change the way you look at programming. I'm excited about this
> "enlightenment", but frustrated at the fact that it's not coming very
> easily to me...
I'm also beginner in Lisp and I'm currently also reading Grahams book.
The example you were talking about is not so complicated because Lisp is
such a complicated or hard to read language - it is complicated, because
the solution to the described problem is complicated. It is just an
advanced algorithm.
Andr�
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm *also* a Lisp n00b, and I'm *also* coming in from the 'imperative'
cold world and I'm *also* working my way through Graham's (excellent,
in my view) book.
I saw several posts recently, on just that problem - one or two were
very helpful for me, but yes, apparently depth-first searches (?) are
rather advanced.
I usually 'cheat' when I run across a problem like that - I resort to
the old pencil-and-paper computer and run the data through a few
cycles, see what happens.
Though I suppose typing in the function and running with 'trace on'
might be easier, maybe even 'greener', to boot.
+Chris
- --
Democracy: The worship of jackals by jackasses.
- -- H.L. Mencken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 <http://mailcrypt.sourceforge.net/>
iD8DBQFAXJIQrZy455Pig6QRAnVNAJ9QcW+Ww4ftayFSc3pnToDldup45QCfZQ6V
zLZot2O+3PLs/3oPiheLMug=
=jjNv
-----END PGP SIGNATURE-----