A newbie here.
How does quote (or eval, for that matter) actually work?
If I've understood correctly, lists are evaluated from left to right
and then the leftmost value is applied on the rest, say
(foo (bar 1 2))
would apply foo to the value of (bar 1 2). Fair enough.
(quote (bar 1 2))
however, returns (bar 1 2). Ok, so quote would seem to constitute
somewhat of an exception. How is this implemented? If I have
(foo '(bar 1 2))
is it equivalent to having
(foo . (quote . (bar . (1 . (2 . ())))))
and eval then just stopping evaluation at quote, or does read perhaps
parse it into
(foo . ((bar . (1 . (2 . ()))) . ()))
or what happens? This confuses me.
Hello, Nyang. I'll answer to your question, but first a bit of advice:
you should read, if you're not already doing, the book "Practical
Common Lisp" by Peter Seibel, which is freely available online. (Many
other Lisp books exist of course, but I think that is a great book for
beginners).
Then, to answer your question, lists are evaluated as follows: the
first element, the "car", must be a symbol. Symbols, among other
things, can name functions, macros or special forms. Let's ignore
macros for now.
Functions work like you described: first, every argument (the rest, or
"cdr", of the list), is evaluated, then the function is applied to the
evaluated arguments.
Special forms, instead, don't work like this; each special form has
its own rules of evaluation (it is special for a reason). Quote is a
special form: it does not evaluate its argument, instead it returns it
as-is.
So, you could think of eval as (in a very simpliefied C-ish version):
function eval(form) {
if(car(form) == QUOTE) then return cdr(form);
else if ...other special cases...
else return apply(car(form), eval_arguments(cdr(form)));
}
On the syntax level, quote can be replace by the ' character. So 'foo
is read as (quote foo). So yes, (foo '(bar 1 2)) is equivalent to
having (foo . (quote . (bar . (1 . (2 . ()))))), that is, the function
foo would be applied to the list made of the symbol BAR, the number 1,
and the number 2.
Hope it's all clear...
cheers
Alessio Stalla
On Nov 11, 11:22 pm, Alessio <·············@gmail.com> wrote:
> Hello, Nyang. I'll answer to your question, but first a bit of advice:
> you should read, if you're not already doing, the book "Practical
> Common Lisp" by Peter Seibel, which is freely available online. (Many
> other Lisp books exist of course, but I think that is a great book for
> beginners).
Thanks, I'll look into it.
> So, you could think of eval as (in a very simpliefied C-ish version):
>
> function eval(form) {
>
> if(car(form) == QUOTE) then return cdr(form);
> else if ...other special cases...
> else return apply(car(form), eval_arguments(cdr(form)));
>
> }
>
> On the syntax level, quote can be replace by the ' character. So 'foo
> is read as (quote foo). So yes, (foo '(bar 1 2)) is equivalent to
> having (foo . (quote . (bar . (1 . (2 . ()))))), that is, the function
> foo would be applied to the list made of the symbol BAR, the number 1,
> and the number 2.
Yes, that does make sense; eval makes exceptions. Thanks for the
clarification.
What does however still kinda confuse me is then the equivalence of
(pure) Lisp and Lambda calculus (with which I'm not too familiar,
though), as it would appear to me that in Lambda calculus there are no
exceptions to function evaluation, whereas there are in Lisp. It kinda
bothers me, though I'm not sure if that's warranted in any way.
I don't know lambda calculus... but I suspect that the reason lambda
calculus has no quote is that all "objects" used in lambda calculus
evaluate to themselves - Lisp instead, being a practical language and
not a theoretical tool, has some "ambiguities" (e.g. symbols which are
first-class objects but are also used to name variables, functions,
classes, ...) that make it less "pure" but far more useable. Similarly
there are other differencies between math and programming languages,
e.g. in math objects are usually immutable, etc...
> What does however still kinda confuse me is then the equivalence of
> (pure) Lisp and Lambda calculus (with which I'm not too familiar,
> though), as it would appear to me that in Lambda calculus there are no
> exceptions to function evaluation, whereas there are in Lisp. It kinda
> bothers me, though I'm not sure if that's warranted in any way.
Nyang A. Phra wrote:
> What does however still kinda confuse me is then the equivalence of
> (pure) Lisp and Lambda calculus (with which I'm not too familiar,
> though), as it would appear to me that in Lambda calculus there are no
> exceptions to function evaluation, whereas there are in Lisp. It kinda
> bothers me, though I'm not sure if that's warranted in any way.
>
You are balanced on the edge. If you fall this way STFU and get on with
some useful work on Lisp libraries, if you fall that way GTF out of here
and head over to c.l.scheme.
hth, kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
> You are balanced on the edge. If you fall this way STFU and get on with
> some useful work on Lisp libraries, if you fall that way GTF out of here
> and head over to c.l.scheme.
No need for that, Kenny. Last I heard, Common Lisp was
still being counted as a member of the Lisp family, so its
relationship to the lambda calculus is a legitimate topic.
Will
William D Clinger <········@yahoo.com> writes:
> Ken Tilton wrote:
> > You are balanced on the edge. If you fall this way STFU and get on
> > with some useful work on Lisp libraries, if you fall that way GTF
> > out of here and head over to c.l.scheme.
>
> Last I heard, Common Lisp was still being counted as a member
> of the Lisp family, so its relationship to the lambda calculus
> is a legitimate topic.
One can discuss this as an abstract matter, certainly, just for color.
But as a matter of both design (that is, how CL got to be) and also of
practicality (whether it's worth fussing over), Ken's post is (as
always) colorfully worded but makes a good point--there's little point
to being upset over how it is. It is what it is.
And, although I never used McCarthy's original Lisp, it was legit to
ask for that one, too, whether it was all that related to the Lambda
calculus. Inspired by it, certainly. But my recollection is that it
came nowhere close to being a literal implementation of lambda
calculus semantics, nor did the numerous dialects that followed over
the subsequent two decades. Scheme seemed pretty explicitly an
attempt to repair that, taking influence both from Alonzo Church's
work and from Algol, and conjuring a new way to do things.
And certainly CL took influence from Scheme, but chose not to be
neither a Scheme dialect nor an attempt to repatriate the Lambda
calculus with Maclisp.
So it's absolutely fine to discuss differences. What's not fine is to
claim that this community, which is entirely composed of people who,
in full knowledge of the available choices, chose to go this path,
must suddenly acknowledge that the whole path was a lie. I think Ken
is quite on track when he says that the most productive path for someone
who wants things to be done otherwise will find a happier life in
the Scheme community ... however one chooses to characterize those
communities.
As to the material part of what Ken was replying to, that is:
Nyang A. Phra wrote:
> What does however still kinda confuse me is then the equivalence of
> (pure) Lisp and Lambda calculus (with which I'm not too familiar,
> though), as it would appear to me that in Lambda calculus there are no
> exceptions to function evaluation, whereas there are in Lisp. It kinda
> bothers me, though I'm not sure if that's warranted in any way.
The irony is even the Scheme community, which seems a great deal more
concerned about compatibility of this kind, makes some exceptions in
this regard and few complain.
I personally have long said [1] that I think Scheme made an error of
aesthetics in describing its core language with exceptions in the
evaluation rules. I claim that the language would be better served by
rules more like:
* the car of _any_ evaluable form must a special operator
* variable evaluation should be done by a VALUE special operator,
as in (value x) rather than just x.
* function calling should be done by a CALL special operator,
as in (call f x)
* code as written now should be seen as macrology, and a functional
operator should be available by loose analogy to CL's macroexpand
that would prepare a "casual form" for formal evaluation, by rewriting
(lambda (x y) (f y x))
as
(lambda (x y) (call (var y) (var x) (var y)))
and there could even be a reverse expander that re-introduced shorthand.
That would allow anyone doing macro processing on the symbols (not that Scheme
is very fond of that, given the hygiene issue, but that's a separate matter)
to use dispatch that was regular as to how the dispatching went. instead of
something like this (most functions made up, not actual functions, but just
to give the shape):
(define evaluate
(lambda (env form)
(if (symbol? x)
(process-atom env x)
(if (pair? x)
(let ((op (car x)))
(if (special-operator? op)
(process-special env x (car x) (cdr x))
(process-function env x)))
(error)))))
one could just write:
(define evaluate
(lambda (env form)
(if (pair? x)
(process-special env x (car x) (cdr x))
(error))))
I share Nyang's surprise that some dialect of the Lisp/Scheme family has
not appeared to take this path. If your guiding design principle is
aesthetics, it's odd to not notice this gigantic gaping hole in the
set of available names and/or how they are treated. But CL's design
principles [2] explicitly place aesthetics as a lower priority and do not
mention the Lambda calculus, so it's hardly a surprise here. Which is
again why Ken probably suggested this might not be the best group to get
down and dirty in a fight over such matters.
I didn't post my remarks about Scheme on comp.lang.scheme because I
don't see any point to challenging the Scheme community on this matter
either, frankly--they probably have better things to do as well. And
I am not much of a big fan of people showing up from other communities
just to provoke a bunch of happy people into changing something one
doesn't plan to rush out and use.
I hope no one takes any of this post as critical of any community. It's
hard to write anything that's neutrally analytical without the risk of
it being taken personally by someone. I hope follow-ups will also try to
be neutral.
[1] = Mostly just a claim I have made privately, but there are some
allusions to this desire on my part in the (admittedly
quasi-incoherent) SPIEL stuff I put in
http://www.nhplace.com/kent/Half-Baked/
[2] = The best reference I have to X3J13's charter for CL is
http://www.nhplace.com/kent/CL/x3j13-86-020.html
Kent M Pitman wrote:
> I didn't post my remarks about Scheme on comp.lang.scheme because I
> don't see any point to challenging the Scheme community on this matter
> either, frankly--they probably have better things to do as well. And
> I am not much of a big fan of people showing up from other communities
> just to provoke a bunch of happy people into changing something one
> doesn't plan to rush out and use.
That's a nice distinction. Kenny's cross-post to comp.lang.scheme
was probably intended to provoke a bunch of happy people, but not
to provoke them into changing something.
Yes, we have better things to do.
Will
In article <·············@nhplace.com>, ······@nhplace.com
says...
> I personally have long said [1] that I think Scheme made an error of
> aesthetics in describing its core language with exceptions in the
> evaluation rules. I claim that the language would be better served by
> rules more like:
>
> * the car of _any_ evaluable form must a special operator
OK idea. However, it provokes the implementation of user-
defined special operators. I believe the function concept can
be generalized so both today macros and today functions are
only special cases of generalized functions, all runtime only,
so there would be no need for that.
> * variable evaluation should be done by a VALUE special operator,
> as in (value x) rather than just x.
That could be significant improvement. Maybe it is possible to
understand variables as the functions of zero variables; if it
is, it can simplify lot of things. Instead of (value x) one can
write simply (x).
> I share Nyang's surprise that some dialect of the Lisp/Scheme family has
> not appeared to take this path. If your guiding design principle is
> aesthetics, it's odd to not notice this gigantic gaping hole in the
> set of available names and/or how they are treated.
I agree, Scheme did only minor aesthetical improvements.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> * the car of _any_ evaluable form must a special operator
> * variable evaluation should be done by a VALUE special operator,
> as in (value x) rather than just x.
> * function calling should be done by a CALL special operator,
> as in (call f x)
Kent, are you reinventing MDL?
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <·············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>
> > * the car of _any_ evaluable form must a special operator
> > * variable evaluation should be done by a VALUE special operator,
> > as in (value x) rather than just x.
> > * function calling should be done by a CALL special operator,
> > as in (call f x)
>
> Kent, are you reinventing MDL?
Actually, just for the record, though I'm familiar with the existence
of MDL, and I've even seen small bits of MDL code quoted now and then
back in the days when the MIT-DM machine was still running, I actually
never learned it and don't know its specific features. So perhaps I
am, or not, I wouldn't know. I'd certainly be happy to hear a little
historical background on MDL and its key features so I'd know what you
were alluding to. :)
Related to quote semantics, one of the things I do vaguely recall
about it was that it had something people used to describe as a
construct similar to backquote, though perhaps with some inverted
sense of what to evaluate and what not to... I don't remember the
specifics ... but it's probably apropos to a thread on quotation if
you happened to.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Barry Margolin <······@alum.mit.edu> writes:
>
> > In article <·············@nhplace.com>,
> > Kent M Pitman <······@nhplace.com> wrote:
> >
> > > * the car of _any_ evaluable form must a special operator
> > > * variable evaluation should be done by a VALUE special operator,
> > > as in (value x) rather than just x.
> > > * function calling should be done by a CALL special operator,
> > > as in (call f x)
> >
> > Kent, are you reinventing MDL?
>
> Actually, just for the record, though I'm familiar with the existence
> of MDL, and I've even seen small bits of MDL code quoted now and then
> back in the days when the MIT-DM machine was still running, I actually
> never learned it and don't know its specific features. So perhaps I
> am, or not, I wouldn't know. I'd certainly be happy to hear a little
> historical background on MDL and its key features so I'd know what you
> were alluding to. :)
>
> Related to quote semantics, one of the things I do vaguely recall
> about it was that it had something people used to describe as a
> construct similar to backquote, though perhaps with some inverted
> sense of what to evaluate and what not to... I don't remember the
> specifics ... but it's probably apropos to a thread on quotation if
> you happened to.
I never actually used it, but I read the reference manual shortly after
I learned Lisp, so I just have hazy memory of it.
IIRC, it had a separate syntax for lists, (....), versus forms, <...>.
And symbols were self-evaluating, but you could write something like
<value symbol> to evaluate it, and there was a read-macro "." that
expanded to this, so the usual way to use variables was .symbol. There
may also have been a distinction between accessing the local versus
global value.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
William D Clinger wrote:
> Ken Tilton wrote:
>
>>You are balanced on the edge. If you fall this way STFU and get on with
>>some useful work on Lisp libraries, if you fall that way GTF out of here
>>and head over to c.l.scheme.
>
>
> No need for that, Kenny. Last I heard, Common Lisp was
> still being counted as a member of the Lisp family, so its
> relationship to the lambda calculus is a legitimate topic.
No need for what? I was confirming the Deep Insight apparent in the
closing remark of the OP, which you took out so I'll let you put it back
to restore comprehensibility.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Alessio wrote:
> Then, to answer your question, lists are evaluated as follows: the
It is better to speak of "cons" rather than "list" since nil is a list
that is not evaluated according to this rule.
> first element, the "car", must be a symbol. Symbols, among other
> things, can name functions, macros or special forms. Let's ignore
> macros for now.
You miss the case that the car of the cons can be a lambda expression.
All this is actually pretty clearly spelled out in the ANS section
3.1.2.1.2. The ANS is usually not a very good tutorial, but this
section spells out the evaluation model fairly clearly.
On Sun, 11 Nov 2007 12:44:08 -0800, Nyang A. Phra wrote:
> If I have
>
> (foo '(bar 1 2))
>
> is it equivalent to having
>
> (foo . (quote . (bar . (1 . (2 . ())))))
>
> and eval then just stopping evaluation at quote, or does read perhaps
> parse it into
>
> (foo . ((bar . (1 . (2 . ()))) . ()))
>
> or what happens? This confuses me.
According to "practical common lisp" - http://www.gigamonkeys.com/book/
syntax-and-semantics.html (which, as a Lisp newby, I found to be a pretty
good book to get a grip on Lisp)
'(+ 1 2)
is a shorthand for
(quote (+ 1 2))
which, as far as I understand it, is a shorthand for
(list (quote +) (quote 1) (quote 2))
In other words, (quote (some form here)) returns / evaluates to an
"unevaluated list of symbols" containing the elements 'some 'form 'here.
And I don't know the exact mechanics, though I recall that 'something is
tranlated by the Lisp reader (i.e. before the "actual parsing" of forms)
into (quote something) .
As I said, I'm new to Lisp, so if anyone has corrections, I'd be glad to
hear them.
Joost.
On Nov 11, 10:32 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> On Sun, 11 Nov 2007 12:44:08 -0800, Nyang A. Phra wrote:
> > If I have
>
> > (foo '(bar 1 2))
>
> > is it equivalent to having
>
> > (foo . (quote . (bar . (1 . (2 . ())))))
>
> > and eval then just stopping evaluation at quote, or does read perhaps
> > parse it into
>
> > (foo . ((bar . (1 . (2 . ()))) . ()))
>
> > or what happens? This confuses me.
>
> According to "practical common lisp" -http://www.gigamonkeys.com/book/
> syntax-and-semantics.html (which, as a Lisp newby, I found to be a pretty
> good book to get a grip on Lisp)
>
> '(+ 1 2)
>
> is a shorthand for
>
> (quote (+ 1 2))
Right.
>
> which, as far as I understand it, is a shorthand for
>
> (list (quote +) (quote 1) (quote 2))
No. (quote (+ 1 2)) is a basic form.
> In other words, (quote (some form here)) returns / evaluates to an
> "unevaluated list of symbols" containing the elements 'some 'form 'here.
No.
> And I don't know the exact mechanics, though I recall that 'something is
> tranlated by the Lisp reader (i.e. before the "actual parsing" of forms)
> into (quote something) .
Yes.
> As I said, I'm new to Lisp, so if anyone has corrections, I'd be glad to
> hear them.
>
> Joost.
On Sun, 11 Nov 2007 13:50:35 -0800, ······@corporate-world.lisp.de wrote:
> No. (quote (+ 1 2)) is a basic form.
>
>> In other words, (quote (some form here)) returns / evaluates to an
>> "unevaluated list of symbols" containing the elements 'some 'form
>> 'here.
>
> No.
Can you please expand on this?
Joost.
On Nov 11, 10:55 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> On Sun, 11 Nov 2007 13:50:35 -0800, ······@corporate-world.lisp.de wrote:
> > No. (quote (+ 1 2)) is a basic form.
>
> >> In other words, (quote (some form here)) returns / evaluates to an
> >> "unevaluated list of symbols" containing the elements 'some 'form
> >> 'here.
>
> > No.
>
> Can you please expand on this?
>
> Joost.
Try it out:
? (quote (some form here))
(SOME FORM HERE)
(some form here) is clearly not the same as ('some 'form 'here) .
? (equal '(some form here) '('some 'form 'here))
NIL
On Sun, 11 Nov 2007 13:58:59 -0800, ······@corporate-world.lisp.de wrote:
> ? (quote (some form here))
> (SOME FORM HERE)
Which is an "unevaluated list of symbols", at least, that's what I meant.
>
> (some form here) is clearly not the same as ('some 'form 'here) .
>
> ? (equal '(some form here) '('some 'form 'here)) NIL
Right, I see what you mean. What I meant was that (quote (some form
here)) was equivalent to (list 'some 'form 'here) but I agree that my
wording was confus(ing/ed).
Joost.
On Nov 11, 11:08 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> On Sun, 11 Nov 2007 13:58:59 -0800, ······@corporate-world.lisp.de wrote:
> > ? (quote (some form here))
> > (SOME FORM HERE)
>
> Which is an "unevaluated list of symbols", at least, that's what I meant.
>
>
>
> > (some form here) is clearly not the same as ('some 'form 'here) .
>
> > ? (equal '(some form here) '('some 'form 'here)) NIL
>
> Right, I see what you mean. What I meant was that (quote (some form
> here)) was equivalent to (list 'some 'form 'here) but I agree that my
> wording was confus(ing/ed).
Which is not right.
(quote (some form here)) evaluates to the literal list (some form
here) .
Quote allows you to write literal constants (data) in your code.
(list 'some 'form 'here) evaluates to a fresh list (some form here) .
? (defun foo () '(some form here))
FOO
? (eq (foo) (foo))
T
? (defun bar () (list 'some 'form 'here))
BAR
? (eq (bar) (bar))
NIL
>
> Joost.
On Sun, 11 Nov 2007 14:16:29 -0800, ······@corporate-world.lisp.de wrote:
> (quote (some form here)) evaluates to the literal list (some form here)
> .
> Quote allows you to write literal constants (data) in your code.
>
> (list 'some 'form 'here) evaluates to a fresh list (some form here) .
>
> ? (defun foo () '(some form here))
> FOO
> ? (eq (foo) (foo))
> T
> ? (defun bar () (list 'some 'form 'here)) BAR
> ? (eq (bar) (bar))
> NIL
*Light switches on*
Thanks.
Joost.
······@corporate-world.lisp.de wrote:
>
> ? (defun foo () '(some form here))
> FOO
> ? (eq (foo) (foo))
> T
> ? (defun bar () (list 'some 'form 'here))
> BAR
> ? (eq (bar) (bar))
> NIL
That's interesting... apparently foo is returning the same list every
time (pulling it right from its definition), and bar is allocating a new
list (since it is applying the function "list").
(Less interesting, but I'll point it out for newbies; the results may
not be eq, but they will be equalp, because while bar always makes a new
list, they will always use the same symbols, since there is only ever
one of any symbol.)
Thanks for showing us this joswig, I hadn't ever thought of / run into
it before.
In article <·······················@attbi_s22>,
Charles Hoffman <··············@mchsi.com> wrote:
> ······@corporate-world.lisp.de wrote:
> >
> > ? (defun foo () '(some form here))
> > FOO
> > ? (eq (foo) (foo))
> > T
> > ? (defun bar () (list 'some 'form 'here))
> > BAR
> > ? (eq (bar) (bar))
> > NIL
>
> That's interesting... apparently foo is returning the same list every
> time (pulling it right from its definition),
Right, it is a constant list. You are also not allowed to
modify it. Don't use any destructive function that
would alter the list.
> and bar is allocating a new
> list (since it is applying the function "list").
Right. That's its job. LIST creates a new list.
> (Less interesting, but I'll point it out for newbies; the results may
> not be eq, but they will be equalp, because while bar always makes a new
> list, they will always use the same symbols, since there is only ever
> one of any symbol.)
>
> Thanks for showing us this joswig, I hadn't ever thought of / run into
> it before.
On Sun, 11 Nov 2007 21:32:09 +0000, Joost Diepenmaat wrote:
> '(+ 1 2)
>
> is a shorthand for
>
> (quote (+ 1 2))
>
> which, as far as I understand it, is a shorthand for
>
> (list (quote +) (quote 1) (quote 2))
>
> In other words, (quote (some form here)) returns / evaluates to an
> "unevaluated list of symbols" containing the elements 'some 'form 'here.
With some further playing in the SBCL repl trying to simplify my example,
I did find something I don't understand: why does:
(list + 1 2) evaluate to ((LIST '+ '1 '2) 1 2) instead of (+ 1 2) ?
I expected it to work like (list 1 2 3), which evaluates to (1 2 3)
Joost.
On Nov 11, 10:42 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> On Sun, 11 Nov 2007 21:32:09 +0000, Joost Diepenmaat wrote:
> > '(+ 1 2)
>
> > is a shorthand for
>
> > (quote (+ 1 2))
>
> > which, as far as I understand it, is a shorthand for
>
> > (list (quote +) (quote 1) (quote 2))
>
> > In other words, (quote (some form here)) returns / evaluates to an
> > "unevaluated list of symbols" containing the elements 'some 'form 'here.
>
> With some further playing in the SBCL repl trying to simplify my example,
> I did find something I don't understand: why does:
>
> (list + 1 2) evaluate to ((LIST '+ '1 '2) 1 2) instead of (+ 1 2) ?
+ is a variable. Look it up in the CLHS.
Numbers are self-evaluating. 1 evaluates to 1. 2 evaluates to 2.
(quote 1) evaluates to 1. But you don't need to quote numbers.
Symbols are not self-evaluating. They are evaluated as variables.
So if you want a symbol, you need to quote it.
(list '+ '1 '2) evaluates to (+ 1 2).
(list '+ 1 2) evaluates to (+ 1 2) , since numbers to themselves.
>
> I expected it to work like (list 1 2 3), which evaluates to (1 2 3)
>
> Joost.
On Nov 11, 10:55 pm, ·······@corporate-world.lisp.de"
<······@corporate-world.lisp.de> wrote:
> On Nov 11, 10:42 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
>
>
>
> > On Sun, 11 Nov 2007 21:32:09 +0000, Joost Diepenmaat wrote:
> > > '(+ 1 2)
>
> > > is a shorthand for
>
> > > (quote (+ 1 2))
>
> > > which, as far as I understand it, is a shorthand for
>
> > > (list (quote +) (quote 1) (quote 2))
>
> > > In other words, (quote (some form here)) returns / evaluates to an
> > > "unevaluated list of symbols" containing the elements 'some 'form 'here.
>
> > With some further playing in the SBCL repl trying to simplify my example,
> > I did find something I don't understand: why does:
>
> > (list + 1 2) evaluate to ((LIST '+ '1 '2) 1 2) instead of (+ 1 2) ?
>
> + is a variable. Look it up in the CLHS.
>
> Numbers are self-evaluating. 1 evaluates to 1. 2 evaluates to 2.
> (quote 1) evaluates to 1. But you don't need to quote numbers.
>
> Symbols are not self-evaluating. They are evaluated as variables.
> So if you want a symbol, you need to quote it.
I should mention the one exception: keyword symbols evaluate to
themselves.
? :foo
:FOO
Keyword symbols are in the package KEYWORD and are usually written
as :FOO.
>
> (list '+ '1 '2) evaluates to (+ 1 2).
> (list '+ 1 2) evaluates to (+ 1 2) , since numbers to themselves.
>
>
>
> > I expected it to work like (list 1 2 3), which evaluates to (1 2 3)
>
> > Joost.
On Sun, 11 Nov 2007 13:55:46 -0800, ······@corporate-world.lisp.de wrote:
> On Nov 11, 10:42 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
>> On Sun, 11 Nov 2007 21:32:09 +0000, Joost Diepenmaat wrote:
>> I did find something I don't understand: why does:
>>
>> (list + 1 2) evaluate to ((LIST '+ '1 '2) 1 2) instead of (+ 1 2) ?
>
> + is a variable. Look it up in the CLHS.
>
> Numbers are self-evaluating. 1 evaluates to 1. 2 evaluates to 2. (quote
> 1) evaluates to 1. But you don't need to quote numbers.
>
> Symbols are not self-evaluating. They are evaluated as variables. So if
> you want a symbol, you need to quote it.
Yes, I just realized that after posting it.
> (list '+ '1 '2) evaluates to (+ 1 2). (list '+ 1 2) evaluates to (+
> 1 2) , since numbers to themselves.
But that's *not* what's happening - here's what happens in my REPL:
[ more stuff before]
CL-USER> (list + 1 2)
(* 1 2)
CL-USER> (list + 1 2)
((LIST + 1 2) 1 2)
CL-USER> (list 1 2 3)
(1 2 3)
CL-USER> (list + 2 3)
((LIST 1 2 3) 2 3)
CL-USER> (list + 2 3)
((LIST + 2 3) 2 3)
CL-USER> (list + 2 3)
((LIST + 2 3) 2 3)
CL-USER> +
(LIST + 2 3)
CL-USER> (list + 2 3)
(+ 2 3)
So it seems that + acts (more or less?) like * in the SBCL REPL at least.
I should probably take a look at the SBCL/REPL docs.
Joost.
On Nov 11, 11:02 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> On Sun, 11 Nov 2007 13:55:46 -0800, ······@corporate-world.lisp.de wrote:
> > On Nov 11, 10:42 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> >> On Sun, 11 Nov 2007 21:32:09 +0000, Joost Diepenmaat wrote:
> >> I did find something I don't understand: why does:
>
> >> (list + 1 2) evaluate to ((LIST '+ '1 '2) 1 2) instead of (+ 1 2) ?
>
> > + is a variable. Look it up in the CLHS.
>
> > Numbers are self-evaluating. 1 evaluates to 1. 2 evaluates to 2. (quote
> > 1) evaluates to 1. But you don't need to quote numbers.
>
> > Symbols are not self-evaluating. They are evaluated as variables. So if
> > you want a symbol, you need to quote it.
>
> Yes, I just realized that after posting it.
>
> > (list '+ '1 '2) evaluates to (+ 1 2). (list '+ 1 2) evaluates to (+
> > 1 2) , since numbers to themselves.
>
> But that's *not* what's happening - here's what happens in my REPL:
I said + is a variable. Look it up in the Common Lisp Hyperspec.
> [ more stuff before]
>
> CL-USER> (list + 1 2)
You are using the variable + .
> (* 1 2)
> CL-USER> (list + 1 2)
> ((LIST + 1 2) 1 2)
> CL-USER> (list 1 2 3)
> (1 2 3)
> CL-USER> (list + 2 3)
> ((LIST 1 2 3) 2 3)
> CL-USER> (list + 2 3)
> ((LIST + 2 3) 2 3)
> CL-USER> (list + 2 3)
> ((LIST + 2 3) 2 3)
> CL-USER> +
> (LIST + 2 3)
> CL-USER> (list + 2 3)
> (+ 2 3)
>
> So it seems that + acts (more or less?) like * in the SBCL REPL at least.
>
> I should probably take a look at the SBCL/REPL docs.
>
> Joost.
On Sun, 11 Nov 2007 14:04:34 -0800, ······@corporate-world.lisp.de wrote:
> I said + is a variable. Look it up in the Common Lisp Hyperspec.
I'm sorry, you're right - the hyperspec docs cleared up my confusion. I
thought + and * where REPL specific syntactic constructs, I didn't know
they were implemented as actual variables.
Joost.
Joost Diepenmaat <·····@zeekat.nl> wrote:
+---------------
| ······@corporate-world.lisp.de wrote:
| > I said + is a variable. Look it up in the Common Lisp Hyperspec.
|
| I'm sorry, you're right - the hyperspec docs cleared up my confusion. I
| thought + and * where REPL specific syntactic constructs, I didn't know
| they were implemented as actual variables.
+---------------
They are actual variables, but an ANSI CL top-level loop (REPL)
is required to update those variables -- and in fact, all the
variables listed in 25.1.1 -- in a certain way, see:
http://alu.org/HyperSpec/Body/sec_25-1-1.html
http://alu.org/HyperSpec/Body/var_stcm_ststcm_ststst.html
http://alu.org/HyperSpec/Body/var_plcm_plplcm_plplpl.html
http://alu.org/HyperSpec/Body/var_slcm_slslcm_slslsl.html
http://alu.org/HyperSpec/Body/var_-.html
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
P� Sun, 11 Nov 2007 22:32:09 +0100, skrev Joost Diepenmaat
<·····@zeekat.nl>:
> On Sun, 11 Nov 2007 12:44:08 -0800, Nyang A. Phra wrote:
>> If I have
>>
>> (foo '(bar 1 2))
>>
>> is it equivalent to having
>>
>> (foo . (quote . (bar . (1 . (2 . ())))))
>>
>> and eval then just stopping evaluation at quote, or does read perhaps
>> parse it into
>>
>> (foo . ((bar . (1 . (2 . ()))) . ()))
>>
>> or what happens? This confuses me.
>
> According to "practical common lisp" - http://www.gigamonkeys.com/book/
> syntax-and-semantics.html (which, as a Lisp newby, I found to be a pretty
> good book to get a grip on Lisp)
>
> '(+ 1 2)
>
> is a shorthand for
>
> (quote (+ 1 2))
>
> which, as far as I understand it, is a shorthand for
>
> (list (quote +) (quote 1) (quote 2))
Nop. You confusing quoute with the backquote used in macroes.
`(+ 1 2) is (list (quote +) (quote 1) (quote 2))
and (let ((a 1)) `(+ 1 ,a)) is (+ 1 1)
This is useful in macroes where you want to keep most of list elements as
they are but want to change a few.
' or quote just prevents evaluation of the subexpression so
'(+ 1 2) is (quote (+ 1 2)) which returns (+ 1 2)
--
--------------
John Thingstad
On Sun, 11 Nov 2007 23:02:06 +0100, John Thingstad wrote:
> Nop. You confusing quoute with the backquote used in macroes.
>
> `(+ 1 2) is (list (quote +) (quote 1) (quote 2))
>
> and (let ((a 1)) `(+ 1 ,a)) is (+ 1 1)
Ah, right. I was wondering where I got that from, since the below seems
so much simpler:
> ' or quote just prevents evaluation of the subexpression so '(+ 1 2) is
> (quote (+ 1 2)) which returns (+ 1 2)
Joost.
"John Thingstad" <·······@online.no> writes:
> > '(+ 1 2)
> >
> > is a shorthand for
> >
> > (quote (+ 1 2))
Yes.
> > which, as far as I understand it, is a shorthand for
> >
> > (list (quote +) (quote 1) (quote 2))
No. QUOTE does not create structure. It returns a pointer to the
already existing structure which was quoted.
> Nop. You confusing quoute with the backquote used in macroes.
>
> `(+ 1 2) is (list (quote +) (quote 1) (quote 2))
This is actually not quite right either. Especially when commas are
not used, but even sometimes when they are, and sometimes in places
that casual users of backquote may be quite surprised by, the
backquote facility is free to rewrite backquote as quote and not create
new structure after all. That is,
`(+ 1 2) and '(+ 1 2)
have the same issues.
You might think `(+ ,1 ,2) is required to cons new structure, and I
don't have time to do a detailed read on this to tell you where it
says it, but I think a compiler or just the backquote system itself is
free to change this to '(+ 1 2) as well. (There are other more
complicated situations involving variables and nested backquotes that
can also result in this kind of thing.)
In general, as a point of style, if you want to guarantee new
structure is created, for example so you can modify it, you really
MUST use an explicit constructor, and must not assume that either
quote or backquote will ever do that implicitly.
What backquote is for is when you just want to create something of a
given shape AND can promise not to modify the result.
> and (let ((a 1)) `(+ 1 ,a)) is (+ 1 1)
>
> This is useful in macroes where you want to keep most of list elements
> as they are but want to change a few.
Reworded for clarity: This is useful in macros where you want to
create and return a structure made from some of the list elements and
some other items that were not list elements, and where you know that
you will not be subsequently attempting to modify the result.
> ' or quote just prevents evaluation of the subexpression so
> '(+ 1 2) is (quote (+ 1 2)) which returns (+ 1 2)
Yes.
Kent M Pitman wrote:
> This is actually not quite right either. Especially when commas are
> not used, but even sometimes when they are, and sometimes in places
> that casual users of backquote may be quite surprised by, the
> backquote facility is free to rewrite backquote as quote and not
Kent presumably knows this, just a general "interesting" note:
Implementors have a lot of freedom with common lisp backquote.
Some people (especially people coming from scheme, where
(quasiquote ...) exists) can't resist serious backquote trickery, but
often the best/only viable approach for that sort of thing in CL is to
use a reimplementation of backquote.
So Drew McDermott's "ytools" package includes "bq", a backquote-like
facility with some changes and some exposed internals. The ytools
backquote manual section is a perhaps interesting write-up of the
issues around CL backquote and how much freedom implementors have [1]
... Or there's a backquote implementation in appendix C of of cltl2. [2]
[1] http://cs-www.cs.yale.edu/homes/dvm/papers/ytdoc.pdf
[2]
http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node367.html#SECTION003600000000000000000
Nyang A. Phra wrote:
> A newbie here.
>
> How does quote (or eval, for that matter) actually work?
Read the lambda papers, especially "The Art of the Interpreter". See
http://library.readscheme.org/page1.html
Or read Structure and Interpretation of Computer Programs.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Normally, Lisp takes any expression and tries to evaluate it. If it's a
literal (like a number), the value is returned; if a symbol, it looks
for that symbol to be bound to a value and returns the value; if a list,
it looks for the first element (car) to be a symbol is bound to a
function or special form, and tries applying the remaining elements to
it as arguments.
Quote is a special form that stops the evaluation of its argument, and
just returns it as is.
So while the meaning of (foo (bar 1 2)) is "apply the function foo to
the result of applying the function bar to arguments 1 and 2", (foo
'(bar 1 2)) ends up being quite like (foo (list 'bar 1 2)) -- that is,
"apply the function foo to one argument which is a list containing the
symbol foo, the number 1, and the number 2."
In article <·······················@attbi_s22>,
Charles Hoffman <··············@mchsi.com> wrote:
> Normally, Lisp takes any expression and tries to evaluate it. If it's a
> literal (like a number), the value is returned; if a symbol, it looks
> for that symbol to be bound to a value and returns the value; if a list,
> it looks for the first element (car) to be a symbol is bound to a
> function or special form, and tries applying the remaining elements to
> it as arguments.
It might be interesting that not all Lisp dialects
will evaluate (all types of) data to itself. In older dialects
you often had to quote data, so that the Lisp system
does not try to evaluate data. With Common Lisp this is no
longer necessary.
>
> Quote is a special form that stops the evaluation of its argument, and
> just returns it as is.
>
> So while the meaning of (foo (bar 1 2)) is "apply the function foo to
> the result of applying the function bar to arguments 1 and 2", (foo
> '(bar 1 2)) ends up being quite like (foo (list 'bar 1 2)) -- that is,
> "apply the function foo to one argument which is a list containing the
> symbol foo, the number 1, and the number 2."