look at the following codes , which run in ARC xlisp-stat:
> (eq nil (quote nil))
T
It means that the 2 object nil and (quote nil) are identical.
I has been well discussed that ''nil => (quote nil) .
Now , if (quote nil) and nil are identical ,
why not ''nil => nil ?
If ''nil can't be evaluated to nil , what do we mean by "identical"?
+ ··········@bbs.ee.ncu.edu.tw:
| look at the following codes , which run in ARC xlisp-stat:
|> (eq nil (quote nil))
| T
|
| It means that the 2 object nil and (quote nil) are identical.
No. It means that the two objects you name, when evaluated, have
identical results. Namely, nil.
| I has been well discussed that ''nil => (quote nil) .
| Now , if (quote nil) and nil are identical ,
| why not ''nil => nil ?
| If ''nil can't be evaluated to nil , what do we mean by "identical"?
Evaluation again. Each evaluation strips off another quote. Nil has
the special property that it evaluates to itself. So evaluation goes
... ''''nil => '''nil => ''nil => 'nil => nil => nil => nil => ...
Try (eval ''nil): It evaluates to nil. Isn't that in contradiction
with the above? No, because eval is an ordinary function, so its
arguments get evaluated before it sees them. Thus the argument that
gets passed to eval is just 'nil, and eval evalutaes that and gets
nil.
It's the same thing that bit you in your original example: Both
arguments got evaluated before eq ever saw them.
(BTW, beware of eval. If you ever find yourself doing eval, it's a
sure sign you're doing something wrong, unless you're implementing
systems like SLIME.)
--
* 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 寫道：
> + ··········@bbs.ee.ncu.edu.tw:
>
> | look at the following codes , which run in ARC xlisp-stat:
> |> (eq nil (quote nil))
> | T
> |
> | It means that the 2 object nil and (quote nil) are identical.
>
> No. It means that the two objects you name, when evaluated, have
> identical results. Namely, nil.
Now , may I have the honor to have the answer from the author of the
book "Practical Common Lisp" ?
Peter tells us "two objectes are EQ if they are identical".
What do you say about Harald's opinion , Peter?
Sorry , please forgive my trival questions because I am new to lisp and
I believe in Peter's masterpiece.
··········@bbs.ee.ncu.edu.tw writes:
> Harald Hanche-Olsen �����F
>
>> + ··········@bbs.ee.ncu.edu.tw:
>>
>> | look at the following codes , which run in ARC xlisp-stat:
>> |> (eq nil (quote nil))
>> | T
>> |
>> | It means that the 2 object nil and (quote nil) are identical.
>>
>> No. It means that the two objects you name, when evaluated, have
>> identical results. Namely, nil.
>
> Now , may I have the honor to have the answer from the author of the
> book "Practical Common Lisp" ? Peter tells us "two objectes are EQ
> if they are identical". What do you say about Harald's opinion ,
> Peter?
Harold's right. Note, however, that he's using "objects" to refer to
the objects that are evaluated (namely the symbol NIL and a cons cell
whose CAR is QUOTE and whose CDR is another cons cell whose CAR is the
symbol NIL and whose CDR is, wait for it, the symbol NIL) while in the
bit of my book you quote I'm referring to the objects that are the
result of evaluating those objects since those are the ones that are
passed to EQ.
Since both of the expression objects evaluate to the same thing--the
symbol NIL--EQ returns true. It's much like:
CL-USER> (defparameter *list* (list "a" "b" "c"))
*LIST*
CL-USER> (eq (car *list*) (first *list*))
T
The s-expressions (car *list*) and (first *list*) are not identical
objects but they both evaluate to he same object, namely the string
"a" stored in the CAR of the first cons cell in *LIST*.
> Sorry , please forgive my trival questions because I am new to lisp
> and I believe in Peter's masterpiece.
I'm flattered that you put so much faith in my book. Perhaps, then,
you'll take a bit of friendly advice--don't worry to much about this
esoteric terminology stuff. Learn to use the language and then become
a language lawyer if you want. But if you aspire to the language bar
you'll need to spend some time banging your head against the
hyperspec, not just reading my book. Also, you should note that
xlisp-stat is not a Common Lisp so you may run into differences in
behavior. There are plenty of free (for almost all values of "free")
Common Lisp implementations; it's worth the time to install one of
them. Or grab one of my Lispbox distros from:
<http://www.gigamonkeys.com/lispbox/>
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
With respect to XLispStat being a system not derived from CommonLisp,
I've started from Luke Tierney's CL version (only alpha-level,
semi-broken, definitely archaic CL code from '89/'90 or so) and have
been moving it into ANSI CL recently. Having spent the last few years
immerged with R (a related statistical language), it's been simply
amazing how much easier some of the code (statistical model fitting
strategies) is to write in Common Lisp(Stat).
Hopefully it'll be ready to be critiqued in the next month or so (I've
figure out ASDF, and have a few more related modern technologies to
incorporate, maybe or maybe not graphics, which was the unimplemented
missing piece wat back when)
best,
-tony
··········@gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily
roll-back your mistakes" (AJR, 4Jan05).
···········@gmail.com" <··········@gmail.com> writes:
> With respect to XLispStat being a system not derived from
> CommonLisp, I've started from Luke Tierney's CL version (only
> alpha-level, semi-broken, definitely archaic CL code from '89/'90 or
> so) and have been moving it into ANSI CL recently. Having spent the
> last few years immerged with R (a related statistical language),
> it's been simply amazing how much easier some of the code
> (statistical model fitting strategies) is to write in Common
> Lisp(Stat).
So do you have an implementation of XLispStat *in* Common Lisp (i.e. a
different language) or have you created a package of statistics foo
written in Common Lisp (i.e. a library)?
-Peter
P.S. I have a soft spot in my heart fo Xlisp-Stat because I used it
back around 1992 for things having nothing to do with statistics
because it was the only free-as-in-beer Lisp I could find that ran on
my Macintosh SE/30.
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Basically, XLispStat was LispStat in XLisp. CommonLispStat was to be
LispStat in CommonLisp. CommonLispStat derived from the same base as
Luke's XLispStat, but targetted Common Lisp implementations (Kyoto,
Allegro, and a third I'm forgetting, via CLtL1 and CLtL2 -- this was
'89/'90, after all!)
Luke stopped with an initial alpha version, for various sane reasons --
my goals right now are:
1. to hone my Common Lisp skills to a decent level
2. to finish the conversion (updating to ANSI, targetting CMUCL, SBCL,
and CLISP initially)
3. to add a graphics subsystem to replace the XLisp crossplatform (i.e.
nearly identical on Windows, Macs, Unices -- who would've though about
that in '89?) system -- this is what I think will be the hardest.
Luke has notes about that, with respect to using Garnet. I'm starting
to look at that, McCLIM, and Cello as possible targets.
4. rationalize the FFI with either UFFI or CFFI. Verrazano + CFFI
looks good for what I'd like (I had a running ultra-low cost scalable
virtual reality statistical data analysis environment based on
VRJuggler and R (laptop to CAVE/C-6 configuration) that I'd like to
eventually reimplement. Current FFI is adhoc hacks into the three CL's
that it was being targetted for. Not terribly portable.
5. get it back into the game (currently taken by R, but it's always
good to have living competition).
More aggressive on the list would be to replace the Object system
(prototype based) with CLOS or reimplement prototyping on MOP. This
would make it an interactive statistical system on Lisp, rather than a
"LispStat" (as defined by Luke's book) since it would have a different
object system.
Note that R's "S4" object system _IS_ generic-function based. So CLOS
feels rather comfortable to me. But rewriting a working system is a
big job.
Also, I'm looking at a CLOS-based statistical environment. But that's
even futher in the future, since it's just a
"kill-time-on-the-tram-commute" project. On the other hand, doing
statistical design and analysis using only generics such as:
specifiy-model
design-study
create-data
analyze-model
display
seems like a nice goal.
best,
-tony
··········@gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).
Tony (··········@gmail.com) wrote:
> Basically, XLispStat was LispStat in XLisp. CommonLispStat was to be
> LispStat in CommonLisp.
I think it's great that you are working on converting XLispStat to
modern Common Lisp. I thought about doing this myself, but I'm not
good enough at statistics and I don't need it badly enough.
> 2. to finish the conversion (updating to ANSI, targetting CMUCL, SBCL,
> and CLISP initially)
When you finish this, let me know and I'll try to find the time to
port it to Allegro and Lispworks.
> 3. to add a graphics subsystem to replace the XLisp crossplatform (i.e.
> nearly identical on Windows, Macs, Unices -- who would've though about
> that in '89?) system -- this is what I think will be the hardest.
I'm afraid I have to agree. For commercial apps, both Franz and
Lispworks offer good cross platform solutions. But for open source,
it looks like a difficult choice to me.
> I'm starting to look at [Garnet], McCLIM, and Cello as possible targets.
I would have loved to recommend McCLIM, but AFAIK there's no Windows
back end at the moment and my impression is that the current group
of McCLIM hackers won't be interested in writing one. That can always
change of course, but you can't count on that.
> 5. get it back into the game (currently taken by R, but it's always
> good to have living competition).
Sounds like a good goal to me. I looked at the R language a while
ago and wasn't very impressed by the umpteenth little language that
looked like it was written by people who didn't understand what Common
Lisp has to offer.
> More aggressive on the list would be to replace the Object system
> (prototype based) with CLOS or reimplement prototyping on MOP.
I would be inclined to stick to normal CLOS unless the prototype
based object system has a very clear advantage.
> This would make it an interactive statistical system on Lisp, rather
> than a "LispStat" (as defined by Luke's book) since it would have a
> different object system.
Sounds great to me. Good luck with your project.
··········@gmail.com wrote:
> More aggressive on the list would be to replace the Object system
> (prototype based) with CLOS or reimplement prototyping on MOP.
It seems to me that implementing a prototype-based object system on top
of the CLOS MOP is far from trivial. It is tricky to get the delegation
semantics expressed in terms of the generic function invocation
protocol. I have recently managed to implement a first version of a
prototype-based version with the CLOS MOP, but so far it only works on
one or two CLOS implementations. It's probably more straightforward to
implement a prototype-based system from scratch.
In a sense, CLOS already supports a prototype-based model if you view
things from a slightly twisted perspective: since CLOS classes are
objects themselves, and CLOS supports inheritance between classes, you
effectively have inheritance between these special kinds of objects.
Here is an example:
(defclass pascal ()
; yeah, I am a class! ;)
((name :accessor name
:allocation :class
:initform "Pascal")))
(defclass pascal-as-employee (pascal)
; yeah, a role object that delegates to another object!
((employer :accessor employer
:allocation :class
:initform "Vrije Universiteit Brussel")))
The only problem is that you typically cannot invoke generic functions
directly on those objects, but have to use their prototype representations:
(print (employer (class-prototype (find-class 'pascal-as-employee))))
(print (name (class-prototype (find-class 'pascal-as-employee))))
That's quite a mouthful. But maybe a handful of macros help to make this
look nicer...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
+ Peter Seibel <·····@gigamonkeys.com>:
| Harold's right.
If you say so. Whoever he may be. 8-)
--
* 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:
> + Peter Seibel <·····@gigamonkeys.com>:
>
> | Harold's right.
>
> If you say so. Whoever he may be. 8-)
Whoops! Sorry.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
··········@bbs.ee.ncu.edu.tw wrote:
> look at the following codes , which run in ARC xlisp-stat:
>
>> (eq nil (quote nil))
>
> T
>
> It means that the 2 object nil and (quote nil) are identical.
No, it means that the values that nil and (quote nil) evaluate to are
identicaly.
This is very much the same situation as in (eql 3 (+ 1 2)) - this also
doesn't mean that 3 and (+ 1 2) are the same objects. Likewise, 3 and
(quote (+ 1 2)) shouldn't return the same values either.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Joe Marshall
Subject: Re: What do we mean by "Identical" ?
Date:
Message-ID: <slujycyb.fsf@alum.mit.edu>
··········@bbs.ee.ncu.edu.tw writes:
> look at the following codes , which run in ARC xlisp-stat:
>> (eq nil (quote nil))
> T
>
> It means that the 2 object nil and (quote nil) are identical.
No, it means that the value of the identifier nil is the symbol nil.
Thanks for all the replies.
I try to find the answer in CLtL2 , and the follwoing is what it says
in the "6.3. Equality Predicates":
"(eq x y) is true if and only if x and y are the same identical object.
(Implementationally, x and y are usually eq if and only if they address
the same identical memory location.) "
So, while eq return true , the 2 following objects are really identical
, not only evaluated to the same thing .
Now I got more and more confused :
If nil and 'nil are really identical (as shown by T=(eq nil 'nil)), why
not ''nil ='('nil)='nil=nil ?
OK , I am willing to forget this problem , but I beg someone's answer
for another question:
Do you really think that nil and 'nil take the same identical memory
locations ?
Many thanks!!
There is still further examples :
> (eq (= 1 2) (= 3 4))
T
Does anybody still believe what's said in the CLtL2 ?
I can't believe that the 2 objects (= 1 2) and (= 3 4) are identical.
Anybody believes that they are identical ?
Anybody believes that they share the same menorial location ?
+ ··········@bbs.ee.ncu.edu.tw:
| There is still further examples :
|
|> (eq (= 1 2) (= 3 4))
| T
|
| Does anybody still believe what's said in the CLtL2 ?
| I can't believe that the 2 objects (= 1 2) and (= 3 4) are identical.
| Anybody believes that they are identical ?
| Anybody believes that they share the same menorial location ?
You are confused on a very deep level. This has been explained to you
so many times I don't know what to try next. Repeat after me, please:
BEFORE A FUNCTION IS CALLED, ALL ITS ARGUMENTS ARE EVALUATED.
Repeat it twice more. Then, the step-by step analysis:
(= 1 2) is evaluated, result nil.
(= 3 4) is evaluated, result nil.
eq is called with the two results: nil and nil.
Since nil is in fact identical to nil, eq returns t.
End of story.
Now I'm off for a Sunday bike ride. We're having unseasonally warm
weather now, thanks I'm told to hurricane Wilma, whose remains have
come across the Atlantic to warm these usually frigid lands. When I'm
back, I want to hear that you have mastered this very nasty stumbling
block. Okay? (If not, I'll leave your case in the hands of more able
pedagogues than myself.)
--
* 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 , I sincerely wish you have good time during your riding in the
warm breeze.
I think there is misunderstanding between us. I am not a pedagog. In
fact , I have confessed that I am new to lisp.
I believe that you are right that the arguments should be evaluated
before the calling of the function , but this still makes me more and
more confused . What do you think makes "eq" different from "eql"?
Following those procedures you taught me , I can't tell "eq" apart from
"eql".
Again , in "Practical Common Lisp" , Peter tells us that "expression
(eq 3 3) can legally evaluate to either true or false" . Following your
procedures , I'm too foolish to see why it is possible for (eq 3 3 ) to
evaluate to false.
Many thanks if anyone can give me a hint !
··········@bbs.ee.ncu.edu.tw wrote:
> Harald , I sincerely wish you have good time during your riding in the
> warm breeze.
> I think there is misunderstanding between us. I am not a pedagog. In
> fact , I have confessed that I am new to lisp.
>
> I believe that you are right that the arguments should be evaluated
> before the calling of the function , but this still makes me more and
> more confused . What do you think makes "eq" different from "eql"?
> Following those procedures you taught me , I can't tell "eq" apart from
> "eql".
>
> Again , in "Practical Common Lisp" , Peter tells us that "expression
> (eq 3 3) can legally evaluate to either true or false" . Following your
> procedures , I'm too foolish to see why it is possible for (eq 3 3 ) to
> evaluate to false.
>
> Many thanks if anyone can give me a hint !
Only because the spec says so: "numbers with the same value need not be
eq". If an implementation uses EQ to compare memory addresses, maybe
the two 3's are stored in different memory locations.
http://www.lisp.org/HyperSpec/Body/fun_eq.html
There are multiple equality operators in Common Lisp. After all, what
is the philosophical meaning of "equality"?
So:
(eq 3 3) is not always true, but might be.
http://www.lisp.org/HyperSpec/Body/fun_eq.html
(eql 3 3) is always true.
http://www.lisp.org/HyperSpec/Body/fun_eql.html#eql
(equal 3 3) is always true.
http://www.lisp.org/HyperSpec/Body/fun_equal.html#equal
(equalp 3 3) is always true.
http://www.lisp.org/HyperSpec/Body/fun_equalp.html#equalp
(= 3 3) is always true.
http://www.lisp.org/HyperSpec/Body/fun_eqcm_sleq__lteqcm_gteq.html#EQ
Tayssir
From: Joe Marshall
Subject: Re: What do we mean by "Identical" ?
Date:
Message-ID: <sluj6l92.fsf@alum.mit.edu>
··········@bbs.ee.ncu.edu.tw writes:
> Harald , I sincerely wish you have good time during your riding in the
> warm breeze.
> I think there is misunderstanding between us. I am not a pedagog. In
> fact , I have confessed that I am new to lisp.
>
> I believe that you are right that the arguments should be evaluated
> before the calling of the function , but this still makes me more and
> more confused . What do you think makes "eq" different from "eql"?
> Following those procedures you taught me , I can't tell "eq" apart from
> "eql".
>
> Again , in "Practical Common Lisp" , Peter tells us that "expression
> (eq 3 3) can legally evaluate to either true or false" . Following your
> procedures , I'm too foolish to see why it is possible for (eq 3 3 ) to
> evaluate to false.
In my version of Lispworks, I can do this:
(eq 3 3)
=> T
(eq 1234567890 1234567890)
=> NIL
(eql 1234567890 1234567890)
=> T
What gives? EQ compares the bit patterns stored in the machine
registers. Small numbers like 3 fit in a register so the bits are the
same. Large numbers like 1234567890 are stored at some memory address
and there may be multiple copies. The bit patterns will have the
address of one of the copies and it may not match the other.
EQL special cases large numbers (and characters) so you don't have
this weird behavior. Otherwise they are the same.
··········@bbs.ee.ncu.edu.tw wrote:
> I believe that you are right that the arguments should be evaluated
> before the calling of the function , but this still makes me more and
> more confused . What do you think makes "eq" different from "eql"?
> Following those procedures you taught me , I can't tell "eq" apart from
> "eql".
It is true that for most values, eq and eql behave exactly the same. The
only exceptions are characters and numbers, and this is for technical
reasons. Since you are a newbie, I would suggest to you to forget about
eq for the time being and always use eql when you want to test for
identity. eq is really only an optimized variation of eql that you can
use when you are sure about what you are doing, that is when you are
absolutely sure that you are _not_ comparing characters or numbers. You
will get back to this later when optimization issues become more
important in your programs...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Sun, 30 Oct 2005 12:25:30 +0100, <··········@bbs.ee.ncu.edu.tw> wrote:
> Harald , I sincerely wish you have good time during your riding in the
> warm breeze.
> I think there is misunderstanding between us. I am not a pedagog. In
> fact , I have confessed that I am new to lisp.
>
> I believe that you are right that the arguments should be evaluated
> before the calling of the function , but this still makes me more and
> more confused . What do you think makes "eq" different from "eql"?
> Following those procedures you taught me , I can't tell "eq" apart from
> "eql".
>
> Again , in "Practical Common Lisp" , Peter tells us that "expression
> (eq 3 3) can legally evaluate to either true or false" . Following your
> procedures , I'm too foolish to see why it is possible for (eq 3 3 ) to
> evaluate to false.
>
> Many thanks if anyone can give me a hint !
>
NIL is always stored in the same place in memory.
(or rather it is defined to behave as though it was)
Same for T.
These are the ONLY elements with are guaranteed to have these properties.
The reason for nil having it is to make list prosessing more efficent I
would think.
(Imagine the waste if each list had a unique nil element)
Also NIL is the ONLY object that does not inherit from T.
So.. any expression that does not evaluate to nil is T in Lisp generalized
boolean.
(if 1 ..) gives the same result as (if 2 ...) or (if "hello" ...)
Expressions on the form nil, T, some number, a string are called self
evaluating.
That is.. When 'called' during the parsing of the paramenters they return
themselves.
Also a function call (func ..) is T unless it returns nil.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> writes:
> Also NIL is the ONLY object that does not inherit from T.
What do you mean?
An object may be an instance of a class.
A class may inherit from another class.
But unless we have an object model where the dichotomy between objects
and classes doesn't exist, an object doesn't inherit from another object.
That said in CL, T is a "class", and NIL is an instance of (a subclass
of) the class T:
(typep NIL 'T) --> T
#+clisp (clos::subclassp (find-class 'null) (find-class 't)) --> T
> So.. any expression that does not evaluate to nil is T in Lisp
> generalized boolean.
It is not T, it is true.
> (if 1 ..) gives the same result as (if 2 ...) or (if "hello" ...)
> Expressions on the form nil, T, some number, a string are called self
> evaluating.
> That is.. When 'called' during the parsing of the paramenters they
> return themselves.
> Also a function call (func ..) is T unless it returns nil.
Not T, true.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
On Sun, 30 Oct 2005 17:49:16 +0100, Pascal Bourguignon
<····@mouse-potato.com> wrote:
> "John Thingstad" <··············@chello.no> writes:
>> Also NIL is the ONLY object that does not inherit from T.
>
> What do you mean?
>
> An object may be an instance of a class.
> A class may inherit from another class.
>
> But unless we have an object model where the dichotomy between objects
> and classes doesn't exist, an object doesn't inherit from another object.
>
>
> That said in CL, T is a "class", and NIL is an instance of (a subclass
> of) the class T:
>
> (typep NIL 'T) --> T
>
> #+clisp (clos::subclassp (find-class 'null) (find-class 't)) --> T
>
>
>> So.. any expression that does not evaluate to nil is T in Lisp
>> generalized boolean.
>
> It is not T, it is true.
>
>
>> (if 1 ..) gives the same result as (if 2 ...) or (if "hello" ...)
>> Expressions on the form nil, T, some number, a string are called self
>> evaluating.
>> That is.. When 'called' during the parsing of the paramenters they
>> return themselves.
>> Also a function call (func ..) is T unless it returns nil.
>
> Not T, true.
>
>
Sorry, strike inherit. Make that 'The ONLY object that dosn't evaluate to
true'.
Inheritance is irrelevant in the context anyhow.
The seperate type system and class system make me a bit nuts sometimes.
(By the way Pacal mentioned that eq != eql only for numbers and chars.
As far as I can see it holds for strings and bitvectors too..
look up equal in CLHS)
Anyhow for a beginner eql (elements same type and value) and equal
(elements isomorphic) seem sufficient.
well, also string=, char=, =
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
+ ··········@bbs.ee.ncu.edu.tw:
| Harald , I sincerely wish you have good time during your riding in the
| warm breeze.
It was a perfect day, if too short.
| I think there is misunderstanding between us. I am not a pedagog.
No; it is I who pretend to be.
| In fact , I have confessed that I am new to lisp.
Absolutely. That is clear. What I meant to say is that if I cannot
explain this in a way to make you understand, maybe someone else can.
The trick. from a pedagogical point of view, is to understand the
exact nature of your misunderstanding. Without this, an explanation
is only so many words that do not produce enlightenment.
| I believe that you are right that the arguments should be evaluated
| before the calling of the function,
Not "should be". "Are". It is how Common Lisp works.
Anyway, there is such a crowd of helpful folks around here I am gonna
fade into the background and obvserver a bit.
--
* 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
From: Joe Marshall
Subject: Re: What do we mean by "Identical" ?
Date:
Message-ID: <wtjv6lli.fsf@alum.mit.edu>
··········@bbs.ee.ncu.edu.tw writes:
> There is still further examples :
>
>> (eq (= 1 2) (= 3 4))
> T
>
> Does anybody still believe what's said in the CLtL2 ?
I believe most of what is said in CLtL2.
> I can't believe that the 2 objects (= 1 2) and (= 3 4) are identical.
The two parenthesised forms are obviously different, but their
*values* are the same. Both are false.
On Sun, 30 Oct 2005 07:49:47 +0100, <··········@bbs.ee.ncu.edu.tw> wrote:
> Thanks for all the replies.
> I try to find the answer in CLtL2 , and the follwoing is what it says
> in the "6.3. Equality Predicates":
>
> "(eq x y) is true if and only if x and y are the same identical object.
> (Implementationally, x and y are usually eq if and only if they address
> the same identical memory location.) "
>
> So, while eq return true , the 2 following objects are really identical
> , not only evaluated to the same thing .
>
> Now I got more and more confused :
> If nil and 'nil are really identical (as shown by T=(eq nil 'nil)), why
> not ''nil ='('nil)='nil=nil ?
>
> OK , I am willing to forget this problem , but I beg someone's answer
> for another question:
> Do you really think that nil and 'nil take the same identical memory
> locations ?
>
> Many thanks!!
>
If in doubt substitute 'expr with (quote expr).
Again eq works on the value these functions return.
(eq (quote nil) nil) say runs (quote nil) nil then (eq nil nil)
(quote (quote nil)) returns (quote nil). That is the second term is not
evaluated.
(quote (car nil)) simularly returns (car nil).
nil is a self evaluating form so a single (quote nil) returns nil.
Hope that helps.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Joe Marshall
Subject: Re: What do we mean by "Identical" ?
Date:
Message-ID: <1x2380a9.fsf@alum.mit.edu>
··········@bbs.ee.ncu.edu.tw writes:
> Thanks for all the replies.
> I try to find the answer in CLtL2 , and the follwoing is what it says
> in the "6.3. Equality Predicates":
>
> "(eq x y) is true if and only if x and y are the same identical object.
> (Implementationally, x and y are usually eq if and only if they address
> the same identical memory location.) "
>
> So, while eq return true , the 2 following objects are really identical
> , not only evaluated to the same thing .
You are confusing yourself with naming.
Consider this: Is the letter `x' the same thing as the letter `y'?
Of course not. Yet it is possible for (eq x y) to return true. How
can this be?
When I write (eq x y), I don't mean that I should check whether the
identifier X is the same as the identifier Y. It obviously isn't. I
want to check if the *value* of the variable X is the same as the
*value* of the variable Y.
> Now I got more and more confused :
> If nil and 'nil are really identical (as shown by T=(eq nil 'nil)), why
> not ''nil ='('nil)='nil=nil ?
Forget nil. Try this:
(defconstant foo 'bar) ;; define a constant foo with value 'bar
(eq foo 'bar) ;; returns true
(eq 'foo ''bar) ;; returns false
Do you understand this?
> OK , I am willing to forget this problem , but I beg someone's answer
> for another question:
> Do you really think that nil and 'nil take the same identical memory
> locations ?
The value of the variable NIL is the symbol NIL.
··········@bbs.ee.ncu.edu.tw wrote:
> look at the following codes , which run in ARC xlisp-stat:
> > (eq nil (quote nil))
> T
>
> It means that the 2 object nil and (quote nil) are identical.
No, it doesn't mean that at all. It means that the expressions NIL and
(QUOTE NIL) produce the same object.
Get it? Big difference. NIL and (QUOTE NIL) are not being treated as
objects but as expressions. Here, they are code, not data!
Yes (QUOTE NIL) is also an object: it's a list of two symbols, QUOTE
and NIL. But here, that list behaves as an expression which calls the
QUOTE operator.
The expression (QUOTE X) produces X, so, accordingly, (QUOTE NIL)
produces NIL. And the expression NIL also evaluates to NIL. So (QUOTE
NIL) and NIL produce the same value.
> I has been well discussed that ''nil => (quote nil) .
Which means that the expression (QUOTE (QUOTE NIL))) produces the
object (QUOTE NIL). Yes, the (QUOTE NIL) result is now an object: a
list of two symbols. It's not considered code, but data.
The confusion arises because the source code of Lisp programs is Lisp
data. The data looks like the code, especially when the data includes
symbols that are also used in code, like QUOTE! What adds to the
confusion is that when the data looks like code, the Lisp system prints
it that way, reproducing all of the shorthand notations used for
writing code! For instance, when (QUOTE X) occurs in your data, it is
printed as 'X, and (FUNCTION X) gets printed as #'X and so on --- even
if you don't intend those symbols to represent Lisp operators.
Don't get confused: always know what is code and what is data.
For now, these guidelines should be enough: code is whatever you typed
into your source file or the listener, and anything that is printed
back at you as the result of evaluation is data.
> Now , if (quote nil) and nil are identical ,
> why not ''nil => nil ?
Because ''NIL produces the object 'NIL or (QUOTE NIL). That object is a
non-empty list, in other words a cons cell. The NIL object is an atom.
See? Cons and atom. Different objects.
> If ''nil can't be evaluated to nil , what do we mean by "identical"?
It can be evaluted to nil, if you evaluate it twice! The first
evaluation produces (QUOTE NIL). If you pass that list to the evaluator
again, it will treat it as a Lisp expression, and produce NIL.
(eval ''nil) -> NIL
The first evaluation happens because EVAL is a function, and ''NIL is
its argument. That argument is reduced to 'NIL, and EVAL is called with
that. EVAL reduces 'NIL down to NIL.