[Please just use comp.lang.lisp for this kind of question. It is far too
basic to ask three different newsgroups. I'm replying only to comp.lang.lisp
For more info, see http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
"Roberto" <········@NOSPAMlibero.it> writes:
> Hi all.
> Can anybody explain me
Any Lisp textbook at all should explain this. What are you using
that still left you with a question?
> the difference(s) between
> CONS
Makes a new list from an element and an existing list. The new list is
exactly one element longer than the existing list. The new element is
at the front.
(CONS 'A '(B C D)) => (A B C D)
> APPEND
Takes two (or more) lists and creates a list that contains, respectively,
the elements of each of the given lists.
(APPEND '(A B) '(C D)) => (A B C D)
> LIST
Takes any number of elments and creates a list of those elements.
(LIST 'A 'B 'C 'D) => (A B C D)
> please?
> Thanks a lot!
> Roberto
Not a problem.
.
"Kent M Pitman" <······@nhplace.com> wrote:
> Any Lisp textbook at all should explain this. What are you using
> that still left you with a question?
I study on a little book made by AI 's teacher. It's very little.
Thanks for you help. Now the differences are ok.
Bye
Roberto
Roberto wrote:
> .
>
> "Kent M Pitman" <······@nhplace.com> wrote:
>
>
>>Any Lisp textbook at all should explain this. What are you using
>>that still left you with a question?
>
>
> I study on a little book made by AI 's teacher. It's very little.
> Thanks for you help. Now the differences are ok.
Not so fast! :) What do you think these will do?:
(cons '(a b c) '(1 2 3))
(append 'a '(b c d))
(list 'a '(b c d))
I am not trying to drive you crazy, btw, I just happen to think one has
to be able to predict those results to really understand the differences
(and to use the functions in real-world Lisp).
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Joe Marshall
Subject: Re: [NEWBIE]CONS,APPEND AND LIST
Date:
Message-ID: <wu99n4ti.fsf@comcast.net>
Kenny Tilton <·······@nyc.rr.com> writes:
> Not so fast! :) What do you think these will do?:
>
> (cons '(a b c) '(1 2 3))
> (append 'a '(b c d))
> (list 'a '(b c d))
>
> I am not trying to drive you crazy, btw, I just happen to think one
> has to be able to predict those results to really understand the
> differences (and to use the functions in real-world Lisp).
Before typing those in and testing them, think hard about the types.
Remember that `item' in the sense I use it below means anything
*including* other lists.
CONS (when used for extending lists) takes an ITEM and a LIST and
returns a LIST.
APPEND takes a LIST and a LIST and returns a new LIST. But note that
Kenny did not give it a LIST as a first argument!
(I suspect that Kenny was thinking of (append '(a b c) 'd) which is
different because the *final* argument to append can be an `improper
list'.)
LIST takes a number of ITEMS and returns a LIST.
--
~jrm
Joe Marshall wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Not so fast! :) What do you think these will do?:
>>
>>(cons '(a b c) '(1 2 3))
>>(append 'a '(b c d))
>>(list 'a '(b c d))
>>
>>I am not trying to drive you crazy, btw, I just happen to think one
>>has to be able to predict those results to really understand the
>>differences (and to use the functions in real-world Lisp).
>
>
> Before typing those in and testing them, think hard about the types.
> Remember that `item' in the sense I use it below means anything
> *including* other lists.
>
> CONS (when used for extending lists) takes an ITEM and a LIST and
> returns a LIST.
>
> APPEND takes a LIST and a LIST and returns a new LIST. But note that
> Kenny did not give it a LIST as a first argument!
>
> (I suspect that Kenny was thinking of (append '(a b c) 'd) which is
> different because the *final* argument to append can be an `improper
> list'.)
<g> No, I was going to crash the newbie into a backtrace as an object
lesson. Come to think of it, that's not very nice, is it? But when I
started that post I also showed the resulting error. After a sec I
decided that it would be more helpful if I did not give away the answer.
(Ah, fond memories of the C Puzzle Book, one of the best programming
books ever.)
>
> LIST takes a number of ITEMS and returns a LIST.
>
Where is Peter's book when we need it? :)
http://www.apress.com/book/bookDisplay.html?bID=237
No, I mean the preview chapters available on-line. :) There are lots of
online refs, but his is the first I know of to drive home that there is
no such thing as a list (just cons cells), which I think is the only way
to sort out the confusion once one starts staring at these different
"list"-construction functions.
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:
> Where is Peter's book when we need it? :)
>
> http://www.apress.com/book/bookDisplay.html?bID=237
>
> No, I mean the preview chapters available on-line. :)
Heh. The lists chapter is up next as soon as I finish the chapter on
vectors and hash tables. So hopefully sometime next week that chapter
should be available for review (and for pointing newbies to.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Kenny Tilton writes:
> of online refs, but his is the first I know of to drive home that
> there is no such thing as a list (just cons cells), which I think is
Hmmm... this is a good marketing argument when people start repeating
that Lisp is all about lists :)
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso <·······@mclink.it> writes:
> Kenny Tilton writes:
>
> > of online refs, but his is the first I know of to drive home that
> > there is no such thing as a list (just cons cells), which I think is
>
> Hmmm... this is a good marketing argument when people start repeating
> that Lisp is all about lists :)
And, like many good marketing arguments, it isn't true. :-)
What I mean is that the standard defines a list as either NIL or a
chain of cons cells with the CDR of the last cons cell holding NIL.
Thus lists are enshrined in the standard, so they MUST exist. So the
above can be confusing.
The following may also be confusing....
I think about cons cells as a low level representation, which can be
used for higher level abstractions. In particular, cons cells are the
required implementation for "linked lists" (which are the canonical
lists that Lisp has).
Thus when I'm thinking about cons cells I try to use "car" and "cdr"
to remind myself that I'm dealing with conses, while when I'm thinking
about lists I try to use "first" and "rest". Also, I try to use
"push" and "pop" to deal with inserting and accessing things in lists,
because this helps remind me that I'm dealing with a particular kind
of structure. If I find myself wanting to break this abstraction I
start thinking about using a class, a structure or a
"pseudo-structure" --- a chain of cons cells as a chain of cons cells
and not as a list.
In the latter case, using a chain of cons cells as a pseudo-structure,
I will define functions or macros using the cXXXXXr facility to
abstract the fact that I'm using cons cells. I never use things like
NTHCDR because I feel that if I want random access with a large set of
objects I'll use an array.
To answer the original question I would say the following:
CONS: a low-level function that takes two objects and returns a new
cons, the CAR of which points to the first object and the CDR of which
points to the second object. It has the effect of allocating a piece
of memory to hold the new cons, thus the term "consing".
APPEND: Sort of mid-way between abstraction levels. You give it zero
or more objects, all but the last of which must be a "proper list",
that is, a list that isn't NIL. It creates (if necessary) a new chain
of conses where the CARs of all the conses point to the elements in
the lists, and the CDR of the last cons points to the last object.
From the "list" point of view, it concatenates lists.
LIST: A shortcut for repeated consing. Takes a bunch of objects and
strings them together in a chain of conses. From the "list" point of
view, it creates a list from a bunch of objects. The idea is to think
of LIST as a primitive list maker at the list level of abstraction in
the same way as CONS is a primitive cons maker at the cons level of
abstraction.
One might argue that this is too much for a newbie, but at some point
any good programmer has got to start thinking about abstraction and
levels of abstraction, and this is as good an example as any I can
think of off the top of my head.
--
Fred Gilham ······@csl.sri.com || Progressive (adj): Value-free;
tolerant; non-judgemental. E.g. traditional archery instruction
methods spent tedious hours teaching the archer to hit a bulls-eye.
Progressive methods achieved better results by telling the student
archer to shoot in the manner he or she found most comfortable, then
calling whatever the arrow hit the bulls-eye.
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> You give it zero or more objects, all but the last of which
> must be a "proper list", that is, a list that isn't NIL.
NIL is a proper list. The classification goes like this:
Proper lists:
empty list: (), also known as NIL
non-empty lists
example: (a b c)
Improper lists:
dotted lists
example: (a b c . d)
circular lists
example: (a . #1=(b c . #1#))
These cases cover the NIL object and all conses. Other objects
are not lists at all.
> NIL is a proper list.
Oops....brain fart....
Here's my definition of append re-written, in case anyone cares....
APPEND: Sort of mid-way between abstraction levels. You give it zero
or more objects, all but the last of which must be a "proper list",
that is, a list that ends with NIL (NIL itself being such a list). It
creates (if necessary) a new chain of conses where the CARs of all the
conses point to the elements in the lists, and the CDR of the last
cons points to the last object.
--
Fred Gilham ······@csl.sri.com
"The words of Judge Alex Kozinski, written in 1991, are not very
encouraging. 'What we have learned from the experience of Eastern
Europe and the Soviet Union ... is that you need capitalism to make
socialism work.' In other words, capitalism must produce what
socialism is to distribute." -- Janice Rogers Brown
Fred Gilham wrote:
> Paolo Amoroso <·······@mclink.it> writes:
>
>
>>Kenny Tilton writes:
>>
>>
>>>of online refs, but his is the first I know of to drive home that
>>>there is no such thing as a list (just cons cells), which I think is
>>
>>Hmmm... this is a good marketing argument when people start repeating
>>that Lisp is all about lists :)
>
>
> And, like many good marketing arguments, it isn't true. :-)
Sound Bites 'r Us!
>
> What I mean is that the standard defines a list as either NIL or a
> chain of cons cells with the CDR of the last cons cell holding NIL.
Bzzzt! That's a /proper/ list.
(listp (cons 1 2)) => t
And once you start talking about proper lists, damn, that's a spec, not
a data type.
But hair-splitting aside, for pedagogic reasons I think a bunch of
examples are like looking at a black box trying to guess what is going
on inside. Why not just tell them what is going on inside, which is what
they have to know in order to select from the various list operations?
> To answer the original question I would say the following:
oh, ok. :)
But I would explain list before append,
My turn:
struct cons {
void *car;
void *cdr;
}
void* cons (void *car, void *cdr) (
void *cons = malloc( sizeof cons );
cons->car = car;
cons->cdr = cdr;
return (cons);
}
void* list (int argc, void**argv) {
if (argc) {
cons* = cons(0,0);
cons->car = (*argv)[0];
cons->cdr = list( --argc, ++argv);
return( cons );
} else return( 0 );
}
void* append (int argc, void **listv) {
if (argc) {
l1 = (*argv)[0]);
if (argc > 1) {
l1 = list_copy (l1);
for (cons = l1; cons; cons = cons->cdr) {
if (!cons->cdr)
cons->cdr = append( --argc, ++listv);
}
return( l1);
} return *listv;
}
}
:)
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 wrote:
> But I would explain list before append,
>
> My turn:
>
> struct cons {
> void *car;
> void *cdr;
> }
> ....
I am shocked, shocked to see the above from someone upon whose laptop
John McCarthy himself typed. For shame, sir!
(Do I *have* to put a smiley here?)
--
Fred Gilham ······@csl.sri.com
"The words of Judge Alex Kozinski, written in 1991, are not very
encouraging. 'What we have learned from the experience of Eastern
Europe and the Soviet Union ... is that you need capitalism to make
socialism work.' In other words, capitalism must produce what
socialism is to distribute." -- Janice Rogers Brown
Fred Gilham wrote:
> Kenny Tilton wrote:
>
>
>>But I would explain list before append,
>>
>>My turn:
>>
>>struct cons {
>> void *car;
>> void *cdr;
>>}
>>....
>
>
> I am shocked, shocked to see the above from someone upon whose laptop
> John McCarthy himself typed. For shame, sir!
Aw, c'mon. All the other kids are working on their own Lisp, why can't I? :(
kenny
--
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:
> Fred Gilham wrote:
>
> > I am shocked, shocked to see the above from someone upon whose laptop
> > John McCarthy himself typed. For shame, sir!
>
> Aw, c'mon. All the other kids are working on their own Lisp, why can't I? :(
But aren't they all bootstrapping from Lisp, not C? God, please tell
me they are!
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kenny Tilton <·······@nyc.rr.com> writes:
> for (cons = l1; cons; cons = cons->cdr) {
> if (!cons->cdr)
> cons->cdr = append( --argc, ++listv);
> }
Bzzzt! This would make (append nil '(frob)) return NIL and give
repetititive results when appending three or more lists.
(Consider CLHS section 3.6, although it doesn't directly apply.)
Kalle Olavi Niemitalo wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>> for (cons = l1; cons; cons = cons->cdr) {
>> if (!cons->cdr)
>> cons->cdr = append( --argc, ++listv);
>> }
>
>
> Bzzzt! This would make (append nil '(frob)) return NIL and give
> repetititive results when appending three or more lists.
> (Consider CLHS section 3.6, although it doesn't directly apply.)
Bzzzt! I am delighted my off-hand code (meant only to illustrate how I
would teach list operations) was so good that you saw fit to desk-check
it. I would have taken more care with it, but why bother when the Gotcha
Goons of cll will do my debugging for me? So where's the fix, fer
chrissakes?!
:)
kt
ps. Good lord. Is that the only bug? After ten years of not doing C?
It's hard to imagine, but I must be better than I thought!
--
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:
> So where's the fix, fer chrissakes?!
Here is a version without those two bugs.
void* append (int argc, void **listv) {
if (argc) {
l1 = (*argv)[0]);
if (!l1)
return append( --argc, ++listv);
if (argc > 1) {
l1 = list_copy (l1);
for (cons = l1; cons; cons = cons->cdr) {
if (!cons->cdr) {
cons->cdr = append( --argc, ++listv);
break;
}
}
return( l1);
} return *listv;
}
}
> ps. Good lord. Is that the only bug?
There are twelve others, but a compiler would easily catch them,
and many of them are specific to C. The missing definitions of
variables were a surprise, though. Have you been exposed to Arc?
Kalle Olavi Niemitalo wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>So where's the fix, fer chrissakes?!
>
>
> Here is a version without those two bugs.
>
> void* append (int argc, void **listv) {
> if (argc) {
> l1 = (*argv)[0]);
> if (!l1)
> return append( --argc, ++listv);
> if (argc > 1) {
> l1 = list_copy (l1);
> for (cons = l1; cons; cons = cons->cdr) {
> if (!cons->cdr) {
> cons->cdr = append( --argc, ++listv);
> break;
> }
> }
> return( l1);
> } return *listv;
> }
> }
>
>
>>ps. Good lord. Is that the only bug?
>
>
> There are twelve others, but a compiler would easily catch them,
> and many of them are specific to C. The missing definitions of
> variables were a surprise, though. Have you been exposed to Arc?
Basic. :)
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Roberto wrote:
> Hi all.
> Can anybody explain me the difference(s) between
> CONS
(CONS X Y)
makes a pair like this:
(X . Y)
In other words, X is the CAR of the pair; Y is the CDR of the pair. For
example:
(CONS 1 2) ==> (1 . 2)
(CONS 1 '(2 3)) ==> (1 2 3)
[The pair (1 . (2 3)) is the same thing as (1 2 3)].
> APPEND
(APPEND X Y)
makes a new list by replacing the final nil in X with the list Y. X and
Y must be proper lists. For example:
(APPEND '(1) '(2 3)) ==> (1 2 3)
(In fact, append takes any number of arguments and appends them in this
fashion).
(APPEND '(1 . 2) '(3 . 4))
doesn't work because the arguments are not proper lists (that is, they
are pairs, but their CDRs are not lists). APPEND only works on proper
lists (pairs whose CDRs are lists or NIL).
> LIST
Takes any number of arguments. Returns a list whose elements are the
values of those arguments in the same order they appear in the LIST
form. For example,
(LIST 1) ==> (1)
(LIST 1 2) ==> (1 2)
(LIST 1 2 '(3 4)) ==> (1 2 (3 4))
(LIST (+ 2 3)(* 2 3)) ==> (5 6)
> please?
> Thanks a lot!
> Roberto
>
>
mikel wrote:
>> APPEND
>
>
> (APPEND X Y)
>
> makes a new list by replacing the final nil in X with the list Y. X and
> Y must be proper lists. For example:
>
> (APPEND '(1) '(2 3)) ==> (1 2 3)
>
> (In fact, append takes any number of arguments and appends them in this
> fashion).
>
> (APPEND '(1 . 2) '(3 . 4))
>
> doesn't work because the arguments are not proper lists (that is, they
> are pairs, but their CDRs are not lists). APPEND only works on proper
> lists (pairs whose CDRs are lists or NIL).
Oops; the last argument is allowed to be something other than a proper list.