I can't really help NOT to ask this: how uninterned symbols really
work? I cannot understand why this works:
(defmacro test ()
(let ((v (gensym)))
`(let ((,v 12))
(princ ,v))))
(test)
->
12
while this one doesn't work:
(LET ((#:G2052 12))
(PRINC #:G2052))
->
:
;The variable #:G2052 is unbound.
The latter is exactly the expansion of the former (of course, with the
exception of generated symbols). I cannot understand how does the lisp
reader/compiler actually treat uninterned symbols. Can anyone
enlighten me, please?
I hope my question is not stupid, but I couldn't find a clear answer
to this, anywhere; and I get REALLY irritated when I can't understand
how something works under the hood. I tried to make up a few
"theories" on this, but none seemed good. I can go and examine SBCL's
source code, but I prefer to do that as the last chance!
On Feb 17, 4:27 pm, ···········@gmail.com wrote:
> I can't really help NOT to ask this: how uninterned symbols really
> work? I cannot understand why this works:
>
> The latter is exactly the expansion of the former (of course, with the
> exception of generated symbols). I cannot understand how does the lisp
> reader/compiler actually treat uninterned symbols. Can anyone
> enlighten me, please?
Dunno if this is particularly enlightening, but here goes...
"#: introduces an uninterned symbol whose name is symbol-name. Every
time this syntax is encountered, a distinct uninterned symbol is
created."
<http://www.lispworks.com/documentation/HyperSpec/Body/02_dhe.htm>
"Objects that appear the same when printed are not necessarily eq to
each other. Symbols that print the same usually are eq to each other
because of the use of the intern function."
<http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm>
> I hope my question is not stupid, but I couldn't find a clear answer
> to this, anywhere; and I get REALLY irritated when I can't understand
> how something works under the hood. I tried to make up a few
> "theories" on this, but none seemed good. I can go and examine SBCL's
> source code, but I prefer to do that as the last chance!
Ron Garrett's guide to packages may also be helpful.
<http://www.flownet.com/ron/packages.pdf>
CLtL2 tends to have very readable explanations (though the Hyperspec
supersedes it).
<http://www.supelec.fr/docs/cltl/cltl2.html>
Tayssir
On Feb 17, 4:27 pm, ···········@gmail.com wrote:
> I can't really help NOT to ask this: how uninterned symbols really
> work? I cannot understand why this works:
>
> (defmacro test ()
> (let ((v (gensym)))
> `(let ((,v 12))
> (princ ,v))))
>
> (test)
>
> ->
>
> 12
>
> while this one doesn't work:
>
> (LET ((#:G2052 12))
> (PRINC #:G2052))
You have two different symbols. They both have the same name.
? (eq '#:G2052 '#:G2052)
NIL
But you can construct the above expression to use the same symbol:
? (let ((sym '#:G2052)) (list 'eq (list 'quote sym) (list 'quote
sym)))
(EQ '#:G2052 '#:G2052)
? (eval *)
T
So you don't see the difference when you print the data structure.
Let's change that:
? (setf *print-circle* t)
T
? (let ((sym '#:G2052)) (list 'eq (list 'quote sym) (list 'quote
sym)))
(EQ '#1=#:G2052 '#1#)
If you type above expression to the listener:
? (EQ '#1=#:G2052 '#1#)
T
So Lisp has a reader syntax that allows you to read and write such
datastructures.
>
> ->
>
> :
> ;The variable #:G2052 is unbound.
>
> The latter is exactly the expansion of the former (of course, with the
> exception of generated symbols). I cannot understand how does thelisp
> reader/compiler actually treat uninterned symbols. Can anyone
> enlighten me, please?
>
> I hope my question is not stupid, but I couldn't find a clear answer
> to this, anywhere; and I get REALLY irritated when I can't understand
> how something works under the hood. I tried to make up a few
> "theories" on this, but none seemed good. I can go and examine SBCL's
> source code, but I prefer to do that as the last chance!
On Feb 17, 7:27 am, ···········@gmail.com wrote:
> I can't really help NOT to ask this: how uninterned symbols really
> work? I cannot understand why this works:
>
> (defmacro test ()
> (let ((v (gensym)))
> `(let ((,v 12))
> (princ ,v))))
>
> (test)
>
> ->
>
> 12
>
> while this one doesn't work:
>
> (LET ((#:G2052 12))
> (PRINC #:G2052))
This one doesn't work because it requires interning, which is defeated
by the #: notation.
Interning refers to the memorization of identifiers in a symbol table,
and the closely related process of resolving occurences of the same
identifier to the same object.
The #: notation doesn't perform this unification; it manufactures a
new object every time it is scanned.
Both your symbol objects have the name "G2052", but they are different
objects. A symbol name is just a string property attached to a symbol
which is used when the symbol is to be printed. Symbol names are not
required to be unique.
Uninterned symbols still have names, but those names do not
participate in a symbol table.
>
> ->
>
> :
> ;The variable #:G2052 is unbound.
>
> The latter is exactly the expansion of the former (of course, with the
> exception of generated symbols). I cannot understand how does the lisp
> reader/compiler actually treat uninterned symbols. Can anyone
> enlighten me, please?
>
> I hope my question is not stupid, but I couldn't find a clear answer
> to this, anywhere; and I get REALLY irritated when I can't understand
> how something works under the hood.
Under the hood, you can understand it like this: every time the reader
encounters #:X, it calls (make-symbol "X"). When it encounters X, it
calls (intern "X"). Either way, the returned object is substituted as
the result of reading the notation.
MAKE-SYMBOL simply constructs a brand new symbol object and returns
it.
INTERN searches through the current package (or through the package
specified by its optional second argument) to find an entry for the
given name. If it finds the name, it returns the symbol that is
registered under it. Otherwise it creates a symbol and adds it to the
package and returns that new symbol.
···········@gmail.com wrote:
> I can't really help NOT to ask this: how uninterned symbols really
> work? I cannot understand why this works:
>
> (defmacro test ()
> (let ((v (gensym)))
> `(let ((,v 12))
> (princ ,v))))
>
> (test)
>
> ->
>
> 12
>
> while this one doesn't work:
>
> (LET ((#:G2052 12))
> (PRINC #:G2052))
>
> ->
>
> :
> ;The variable #:G2052 is unbound.
>
> The latter is exactly the expansion of the former (of course, with the
> exception of generated symbols). I cannot understand how does the lisp
> reader/compiler actually treat uninterned symbols. Can anyone
> enlighten me, please?
The latter is _not_ exactly the expansion of the former. It's just the
case that the printed representation of the expansion of the former
looks the same as the latter.
However, in the expansion of the macro, it is guaranteed that both uses
of the generated symbol refer to the same (!!!) symbol. In the latter
form, the two uses of #:G2052 generate different (!!!) symbols that
happen to have the same print name.
In Common Lisp, variables are resolved based on their symbol identity,
not on their (incidental) print name.
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/
> The latter is _not_ exactly the expansion of the former. It's just the
> case that the printed representation of the expansion of the former
> looks the same as the latter.
>
> However, in the expansion of the macro, it is guaranteed that both uses
> of the generated symbol refer to the same (!!!) symbol. In the latter
> form, the two uses of #:G2052 generate different (!!!) symbols that
> happen to have the same print name.
I'm not sure if I understand it correctly. Does that mean that Common
Lisp treats the code generated by macro expansion differently than
other codes? That doesn't seem good! I have always thought of Common
Lisp as being a little bit ugly (in comparison to, say, Scheme) but if
that's the case then it's uglier than I thought!
> In Common Lisp, variables are resolved based on their symbol identity,
> not on their (incidental) print name.
Except during macro expansion?
···········@gmail.com writes:
>> The latter is _not_ exactly the expansion of the former. It's just the
>> case that the printed representation of the expansion of the former
>> looks the same as the latter.
>>
>> However, in the expansion of the macro, it is guaranteed that both uses
>> of the generated symbol refer to the same (!!!) symbol. In the latter
>> form, the two uses of #:G2052 generate different (!!!) symbols that
>> happen to have the same print name.
>
> I'm not sure if I understand it correctly. Does that mean that Common
> Lisp treats the code generated by macro expansion differently than
> other codes?
No, it doesn't. Normally, when the reader (i. e. the function that
reads your _source code_) encounters a symbol, that symbol is interned
(using the function INTERN). INTERN is defined to create a new symbol
if a symbol of the given name doesn't exist yet. If such a symbol
already exists, that symbol is returned. E. g. you read this string:
--8<---------------cut here---------------start------------->8---
"(let ((foo 1)) <-- INTERN creates symbol foo in the current
package
(print foo))" <-- INTERN returns the same symbol foo because a
symbol with that name already exists in the
current package
--8<---------------cut here---------------end--------------->8---
What you get is a list where the two symbols with the name "foo" are
identical because INTERN returned the same symbol when the second
"foo" was read. When this list is handed to EVAL, it should print
"1".
For symbols that start with "#:", the reader behaves differently. It
doesn't call INTERN (hence the name uninterned symbol). Instead, a
new symbol is created every time.
--8<---------------cut here---------------start------------->8---
"(let ((#:foo 1)) <-- Create a symbol called foo (it won't become
part of any package)
(print #:foo))" <-- Create another symbol foo
--8<---------------cut here---------------end--------------->8---
What you get here is a list where the two symbols "foo" are different
because a new symbol was created when the second "foo" was read. When
this list is handed to EVAL, you'll get an error about an unbound
variable.
Now, macro expansion is something else. The reader and INTERN are not
part of it. Instead of reading s-expressions from a string, you
create the forms that will be evaluated directly. E. g. the second
form in this piece of code
--8<---------------cut here---------------start------------->8---
(defmacro foo ()
(let ((g (gensym)))
`(let ((,g 1))
(print ,g))))
(foo)
--8<---------------cut here---------------end--------------->8---
will be macro-expanded to a list that looks like this:
--8<---------------cut here---------------start------------->8---
(let ((#:g2814 1))
(print #:g2814))
--8<---------------cut here---------------end--------------->8---
But here, since we created the list ourselves, the two symbols with
the name "g2814" are identical and EVAL would print "1" again.
[...]
>> In Common Lisp, variables are resolved based on their symbol identity,
>> not on their (incidental) print name.
>
> Except during macro expansion?
No. It's the reader that behaves differently when it sees a symbol
starting with "#:". The rest of Common Lisp pretty much doesn't care
how a symbol looks in printed form.
Peter Seibel has a nice explanation of symbols and packages in his
book, which is available online:
<http://www.gigamonkeys.com/book/programming-in-the-large-packages-
and-symbols.html>
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
···········@gmail.com wrote:
> I have always thought of Common
> Lisp as being a little bit ugly (in comparison to, say, Scheme)
How dare you say that?! CL is /vastly/ uglier than Scheme.
kxo
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On 17 Feb 2007 08:43:36 -0800, ···········@gmail.com tried to confuse everyone
with this message:
>> The latter is _not_ exactly the expansion of the former. It's just the
>> case that the printed representation of the expansion of the former
>> looks the same as the latter.
>>
>> However, in the expansion of the macro, it is guaranteed that both uses
>> of the generated symbol refer to the same (!!!) symbol. In the latter
>> form, the two uses of #:G2052 generate different (!!!) symbols that
>> happen to have the same print name.
>
>I'm not sure if I understand it correctly. Does that mean that Common
>Lisp treats the code generated by macro expansion differently than
>other codes?
Not at all. In the first example you stored the symbol returned by GENSYM into a
variable. Then you use the variable to point to that exact symbol. When you use
symbol's name, it may actually point to different symbol, if the symbol in
question is uninterned. You can use GENSYM outside of macro expansion (although
the usefulness of it is debatable):
(let ((v (gensym)))
(setf (symbol-function v) #'+)
(funcall v 1 2))
results in 3. When you substitute v for #:G2052 it won't work because the
symbols would be different.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
···········@gmail.com wrote:
>> The latter is _not_ exactly the expansion of the former. It's just the
>> case that the printed representation of the expansion of the former
>> looks the same as the latter.
>>
>> However, in the expansion of the macro, it is guaranteed that both uses
>> of the generated symbol refer to the same (!!!) symbol. In the latter
>> form, the two uses of #:G2052 generate different (!!!) symbols that
>> happen to have the same print name.
>
> I'm not sure if I understand it correctly. Does that mean that Common
> Lisp treats the code generated by macro expansion differently than
> other codes? That doesn't seem good! I have always thought of Common
> Lisp as being a little bit ugly (in comparison to, say, Scheme) but if
> that's the case then it's uglier than I thought!
No, all code in Common Lisp is treated the same. When source code is
parsed by the reader (not you, but the algorithm performed by the read
function ;), it generates an s-expression tree consisting of conses,
symbols and other atoms. After reading, all identifiers (functions,
variables, etc.) are resolved based on symbol identity. Common Lisp
never resolves identifiers based on their print names.
>> In Common Lisp, variables are resolved based on their symbol identity,
>> not on their (incidental) print name.
>
> Except during macro expansion?
No, your macro expansion works because (let ((x (gensym)) (eq x x)) is
guaranteed to yield true.
This is actually exactly the same as object identity. Given a class
some-class, (let ((x (make-instance 'some-class))) (eq x x)) is also
guaranteed to yield true.
However, the expression (eq '#:g123 '#:g123) is closer to (eq
(make-instance 'some-class) (make-instance 'some-class)) - in other
words, you are dealing with two different objects here.
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/
Dnia 17.02.2007 Pascal Costanza <··@p-cos.net> napisa�/a:
> However, in the expansion of the macro, it is guaranteed that both uses
> of the generated symbol refer to the same (!!!) symbol. In the latter
> form, the two uses of #:G2052 generate different (!!!) symbols that
> happen to have the same print name.
Indeed! Is every usage of #:G2052 guaranteed to generate a different
symbol than all its previous usages? And if so, why have a GENSYM
function at all, when one could say '#:GENSYM instead?
(eq '#:gensym '#:gensym) => NIL
(let ((x '#:gensym)) (eq x x)) => T
--
Daniel 'Nathell' Janus, GG #1631668, ············@nathell.korpus.pl
"Though a program be but three lines long, someday it will have to be
maintained."
-- The Tao of Programming
It seems I'm understanding it now.
Every time a #: symbol is read it's read as a new symbol. In case of a
macro, we store such symbol (one generated by gensym) into a variable.
Now, in a backquoted list, all occurrences of that symbol actually
refer to the same symbol because they have the same identity (the one
we have stored in the variable and unquoted in the list). When we
print the generated list and read it again, different symbols are
created for every occurrence read. So the same code will not work,
which is actually what we want.
Am I right?
···········@gmail.com writes:
> It seems I'm understanding it now.
>
> Every time a #: symbol is read it's read as a new symbol. In case of a
> macro, we store such symbol (one generated by gensym) into a variable.
> Now, in a backquoted list, all occurrences of that symbol actually
> refer to the same symbol because they have the same identity (the one
> we have stored in the variable and unquoted in the list).
Right.
> When we print the generated list and read it again, different
> symbols are created for every occurrence read.
Yes.
> So the same code will not work, which is actually what we want.
I'm not sure what you mean here. In the case of macros, what we
actually want is to be able to generate new, unique symbols every time
the macro is expanded. It's the only way to avoid unintended variable
captures. For this we have gensym. Occasionally, we might want to
print those symbols, so we need a representation. But what could
happen now is that someone writes #:g1234 in their source code and we
might capture that variable. But this can't happen with uninterned
symbols. Because the reader treats the specially, you have a
guarantee that nobody can write a piece of source code that uses the
same symbol that is generated by one of your macros. Apart from
macros, I don't know of any notable practical uses of uninterned
symbols.
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
From: Vassil Nikolov
Subject: Re: uninterned symbols: how do they really work?
Date:
Message-ID: <yy8vps88rs88.fsf@eskimo.com>
On 17 Feb 2007 09:46:03 -0800, "Wolfram Fenske" <·····@gmx.net> said:
| ...
| Apart from
| macros, I don't know of any notable practical uses of uninterned
| symbols.
E.g. as the third argument (eof-value) to READ. (One of several
options.)
---Vassil.
--
Our programs do not have bugs; it is just that the users' expectations
differ from the way they are implemented.
On Feb 17, 6:25 pm, ···········@gmail.com wrote:
> It seems I'm understanding it now.
>
> Every time a #: symbol is read it's read as a new symbol. In case of a
> macro, we store such symbol (one generated by gensym) into a variable.
> Now, in a backquoted list, all occurrences of that symbol actually
> refer to the same symbol because they have the same identity (the one
> we have stored in the variable and unquoted in the list). When we
> print the generated list and read it again, different symbols are
> created for every occurrence read. So the same code will not work,
> which is actually what we want.
>
> Am I right?
Yes. (Keep in mind you can customize Lisp's reader and printer, in
order to bend/break the default rules when necessary.)
Tayssir
Daniel Janus wrote:
> Dnia 17.02.2007 Pascal Costanza <··@p-cos.net> napisa�/a:
>
>> However, in the expansion of the macro, it is guaranteed that both uses
>> of the generated symbol refer to the same (!!!) symbol. In the latter
>> form, the two uses of #:G2052 generate different (!!!) symbols that
>> happen to have the same print name.
>
> Indeed! Is every usage of #:G2052 guaranteed to generate a different
> symbol than all its previous usages? And if so, why have a GENSYM
> function at all, when one could say '#:GENSYM instead?
>
> (eq '#:gensym '#:gensym) => NIL
> (let ((x '#:gensym)) (eq x x)) => T
'#:g123 generates a fresh symbol at read time, while (gensym) generates
a fresh symbol at runtime. This makes a difference.
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/
On Feb 17, 7:12 pm, Pascal Costanza <····@p-cos.net> wrote:
> Daniel Janus wrote:
> > Indeed! Is every usage of #:G2052 guaranteed to generate a different
> > symbol than all its previous usages? And if so, why have a GENSYM
> > function at all, when one could say '#:GENSYM instead?
>
> > (eq '#:gensym '#:gensym) => NIL
> > (let ((x '#:gensym)) (eq x x)) => T
>
> '#:g123 generates a fresh symbol at read time, while (gensym) generates
> a fresh symbol at runtime. This makes a difference.
For anyone curious, someone explains why this is important. (If you
just create the symbol only at read-time, nested occurrences of the
same macro could lead to name clashes.)
<http://groups.google.com/group/comp.lang.lisp/msg/17f916e2ce8e2edd>
Tayssir
Daniel Janus <············@nathell.korpus.pl> writes:
> Dnia 17.02.2007 Pascal Costanza <··@p-cos.net> napisał/a:
>
>> However, in the expansion of the macro, it is guaranteed that both uses
>> of the generated symbol refer to the same (!!!) symbol. In the latter
>> form, the two uses of #:G2052 generate different (!!!) symbols that
>> happen to have the same print name.
>
> Indeed! Is every usage of #:G2052 guaranteed to generate a different
> symbol than all its previous usages?
No. The wrong word is "usage".
Everytime you READ the characters #\# #\: #\G #\2 #\0 #\5 #\2
the lisp reader(*) will MAKE a new symbol, calling (make-symbol "G2052"),
and not interning it in any package.
This symbol is returned by READ, and thereafter you can use as many
times you want it stays the same symbol.
But if you try to read again the same sequence of characters, you get
a new uninterned symbol.
> And if so, why have a GENSYM
> function at all, when one could say '#:GENSYM instead?
Yes. But for a human, it's easier to read code printed with
*print-circle* = nil and with different names for different symbols.
So GENSYM is still useful to give different names to each uninterned
symbol it returns, and even, you can give a prefix to make it even
easier to read:
(loop repeat 3 collect (list (gensym "FUN") (gensym "ARG") (gensym "RESULT")))
-->
((#:FUN292645 #:ARG292646 #:RESULT292647)
(#:FUN292648 #:ARG292649 #:RESULT292650)
(#:FUN292651 #:ARG292652 #:RESULT292653))
(*) Actually, this is not the lisp reader who does that, but the
reader macro bound to the dispatching reader macro character #\# #\:.
But since this is the behavior specified for the standard reader macro
bound to these characters, we can include it in the lisp reader.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"By filing this bug report you have challenged the honor of my
family. Prepare to die!"
(message (Hello 'Daniel)
(you :wrote :on '(Sat, 17 Feb 2007 17:05:21 +0000 (UTC)))
(
DJ> Indeed! Is every usage of #:G2052 guaranteed to generate a different
DJ> symbol than all its previous usages? And if so, why have a GENSYM
DJ> function at all, when one could say '#:GENSYM instead?
it's possible to use uninterned symbols with same name, but it will make
code very confusing
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"?? ???? ??????? ?????")
In article <···························@students.mimuw.edu.pl>,
Daniel Janus <············@nathell.korpus.pl> wrote:
> Dnia 17.02.2007 Pascal Costanza <··@p-cos.net> napisa�/a:
>
> > However, in the expansion of the macro, it is guaranteed that both uses
> > of the generated symbol refer to the same (!!!) symbol. In the latter
> > form, the two uses of #:G2052 generate different (!!!) symbols that
> > happen to have the same print name.
>
> Indeed! Is every usage of #:G2052 guaranteed to generate a different
> symbol than all its previous usages? And if so, why have a GENSYM
> function at all, when one could say '#:GENSYM instead?
Historical reason: GENSYM predates Common Lisp, packages, and #: syntax.
Esthetic reason: GENSYM has the nice feature of generating a different
symbol name each time it's used (by incrementing the numeric suffix), so
it's easy to see where a symbol is repeated.
To some extent GENSYM was the early solution to the more general problem
that *PRINT-CIRCLE* and #n=/#n# addresses.
--
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 ***
···········@gmail.com writes:
> I can't really help NOT to ask this: how uninterned symbols really
> work? I cannot understand why this works:
>
> (defmacro test ()
> (let ((v (gensym)))
> `(let ((,v 12))
> (princ ,v))))
>
> (test)
>
> ->
>
> 12
>
> while this one doesn't work:
>
> (LET ((#:G2052 12))
> (PRINC #:G2052))
>
> ->
>
> :
> ;The variable #:G2052 is unbound.
>
> The latter is exactly the expansion of the former (of course, with the
> exception of generated symbols).
No, it is not.
C/USER[116]> (setf *print-circle* t)
T
C/USER[117]> (defmacro test ()
(let ((v (gensym)))
`(let ((,v 12))
(princ ,v))))
TEST
C/USER[118]> (macroexpand-1 '(test))
(LET ((#1=#:G292642 12)) (PRINC #1#)) ;
T
With *print-circle* nil you lose information when printing. Notably
the fact that there are two references to the same object in the macro
expansion, but when you read twice #:x you get two different symbols,
with two different pointers.
Reading: (#1=#:HI #1#)
gives:
+---+---+ +---+---+
-->| * | *-|--->| * |NIL|
+-|-+---+ +-|-+---+
| |
+------>+<---+
|
v
+-------+
| "HI" |
+-------+
Reading: (#:HI #:HI)
gives:
+---+---+ +---+---+
-->| * | *-|--->| * |NIL|
+-|-+---+ +-|-+---+
| |
v v
+-------+ +-------+
| "HI" | | "HI" |
+-------+ +-------+
> I cannot understand how does the lisp
> reader/compiler actually treat uninterned symbols. Can anyone
> enlighten me, please?
The rest of the lisp system don't treat uninterned symbol differently
than interned ones. The only difference is that you cannot find an
uninterned symbol with FIND-SYMBOL or INTERN, you need to have a
reference to the uninterned symbol to be able to get at it.
But one important element this shows, with respect to the reader and
the compiler (or EVAL), is that the compiler doesn't intern the
symbols in the forms: the symbols are interned by the reader and all
the compiler (or EVAL) sees are references to the symbol objects. In
particular, the compiler cannot know how the symbols were found or
built.
When you compile:
(defparameter *a*
'(a cl-user::a #.(intern "A" :cl-user) #.(find-symbol "A" "CL-USER")))
all the compiler sees is a list with four references to the same
symbol CL-USER::A
C/USER[121]> (read)
(defparameter *a*
'(a cl-user::a #.(intern "A" :cl-user) #.(find-symbol "A" "CL-USER")))
(DEFPARAMETER *A* '(A A A A))
> I hope my question is not stupid, but I couldn't find a clear answer
> to this, anywhere; and I get REALLY irritated when I can't understand
> how something works under the hood. I tried to make up a few
> "theories" on this, but none seemed good. I can go and examine SBCL's
> source code, but I prefer to do that as the last chance!
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"