Re: Walking a list
- From: Dan Bensen <randomgeek@xxxxxxxxxxxxxx>
- Date: Sat, 30 Jun 2007 10:39:38 -0500
"Leslie P. Polzer" <leslie.polzer@xxxxxxx> wrote:it doesn't let me *save a pointer* to some element in between,
which is the central problem I want to solve in a Lisp way.
Giorgos Keramidas wrote:There are no 'pointers' in Lisp. Once you get past the terminology gap
which separates the two worlds -- the one of C, and the one of Lisp --
you will realize that any Lisp symbol can refer to arbitrary places
within the list
Dan Bensen <randomgeek@xxxxxxxxxxxxxx> wrote:Getting past the 'terminology gap' is not necessary. All the C pro-
grammer has to remember is that all Lisp variables are references,
i.e. implicit pointers with no C-style pointer arithmetic allowed.
Giorgos Keramidas wrote:
I don't really like the confusion which may result from treating Lisp ``symbols'' are C ``pointers''.
There's no confusion for C programmers, and it's variables that are
pointers, not symbols. As Pascal said,
A symbol can conceptually be considered as a structure of 5 slots:
(defstruct symbol package name function value plist)
This description makes perfect sense to a C programmer. A variable
can point to a symbol, and the slots in the symbol point to data.
Mostly because then the need arises for clarifications
of the sort you just mentioned (``implicit pointers
with no C-style pointer arithmetic allowed'').
Again, that's not a problem for a C programmer.
Referring to Lisp symbols as ``pointers'' is not exactly correct.
It's not even close to correct, but I think we've covered that now.
There is a perfectly fine way to refer to them, and that is by
using the word ``symbols'', so that's why I mentioned terminology.
That's not familiar to a C programmer. C programmers understand
pointers very well, but not symbols.
Sometimes, getting the wording correct facilitates better understanding
That applies to all of us. Here's what I said:
All the C programmer has to remember is that all Lisp ***variables*** are references
but YMMV since we are human after all, and everyone has their own way of understanding something :)
Yes, that's true, and I understand that what you're saying probably
makes sense to a long-time Lisper who may not know C. The OP isn't
an experienced Lisper though, so using their language is probably
To summarize, in Lisp, you don't need `pointers' in the C sense, because
every symbol is essentially a pointer to a particular value, and an
arbitrary number of symbols can be bound to the same value.
The OP explicitly asked for the "Lisp way" of solving the problem,
which does require implicit pointers in the Lisp sense, and every C
programmer knows that multiple references can point to the same memory
location. So all the OP really needed to know was how to do what they
Which I demonstrated with an example of two symbols pointing to parts of
the same Lisp object. I don't see what you found wrong about my post
The "terminology gap" comment ("you will realize") suggested that
(1) the OP didn't know that more than one reference can point to the same object, and (2) the only way to cure that ignorance was to submit
to the Lisp Way (TM).
"At this point, stand back ... You will see ..."
Again, this comment suggests that the reader must Behold the
Magnificence of Lisp to understand. Note, btw, that your little arrows
seem to be *pointing* at the data structures, as you yourself even
"To traverse a list, you just need a symbol to 'point'
somewhere inside the list."
Where, to beat an already-dead horse, "symbol" should read "variable".
I understand that symbols are obviously an integral part of Lisp,
but there really are other ways to describe things that people with
other backgrounds will understand better. To more fully address
this comment at the beginning of your post:
"There are no 'pointers' in Lisp."
Lisp is ALL pointers. EVERY variable, EVERY slot in EVERY object
or structure, is a reference to a piece of data. In Lisp, there's
no such thing as directly embedding one object inside another,
as is done in C and C++. There's no such thing as actually
passing an object to a function. The only thing you can contain in
an object or pass to a function is an implicit pointer to the object. If you want to pass a new copy of the object, you have to explicitly
create the copy, and pass a reference to it.