I just ran into an interesting problem while debugging. Apparently, the
symbols I create with gensym are not eq to symbols created by reading
in #:symbolname from the keyboard. I'm using Lucid Sun Common Lisp 4.0.1
Here is a summary:
> (gensym "FOO")
#:FOO236
> (setq s1 (gensym "FOO"))
#:FOO237
> (setq s2 '#:FOO237)
#:FOO237
> (eql s1 s2)
NIL
> (eq s1 s2)
NIL
> (equal s1 s2)
NIL
> (symbol-name s1)
"FOO237"
> (symbol-name s2)
"FOO237"
> (symbol-package s1)
NIL
> (symbol-package s2)
NIL
Is this a bug, am I misreading CLtL2, or is CLtL2 out of date?
Joe Konstan
·······@cs.umn.edu
From: Raymond K. Fink
Subject: Re: Uninterned symbols not eq, eql, or event equal?
Date:
Message-ID: <1992Nov25.204733.2040@inel.gov>
·······@saturn.cs.umn.edu (Joe Konstan) writes:
>I just ran into an interesting problem while debugging. Apparently, the
>symbols I create with gensym are not eq to symbols created by reading
>in #:symbolname from the keyboard. I'm using Lucid Sun Common Lisp 4.0.1
CLtL2, p. 534, on #: "...Every time this syntax is encountered,
a different uninterned symbol is created."
^^^^^^^^^
for example, (eq '#:foo '#:foo) => nil
They are *different* uninterned symbols that just happen to have the
same symbol-name. Like two different people with the same name, they
are not even equalp.
Ray Fink -- Idaho National Engineering Laboratory -- Idaho Falls ID
···@inel.gov 208-525-5431
========== long legal disclaimer follows, press n to skip ===========
Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights. No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory. The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.
... On Wed, 25 Nov 1992 18:40:03 GMT, ·······@saturn.cs.umn.edu (Joe KonstARTICLE 7210
From: Jeff Dalton
Subject: Re: Uninterned symbols not eq, eql, or event equal?
Date:
Message-ID: <8006@skye.ed.ac.uk>
In article <·····················@news2.cis.umn.edu> ·······@saturn.cs.umn.edu (Joe Konstan) writes:
>I just ran into an interesting problem while debugging. Apparently, the
>symbols I create with gensym are not eq to symbols created by reading
>in #:symbolname from the keyboard.
>Is this a bug, am I misreading CLtL2, or is CLtL2 out of date?
It's not a bug, you may be misreading CLtL2 (depends on what parts you
read), and CLtL2 is out of date (though not on this).
#:name creates an uninterned symbol and (page 534) "every time this
syntax is encountered, a different uninterned symbol is created".
From that we can conclude that (eq '#:a '#:a) ==> nil.
So how about the other cases?
There are three ways to get a symbol from a name or string:
1. Just make a symbol. This way you get a new symbol each
time. MAKE-SYMBOL does this. The result is an "uninterned"
symbol, meaning that it is not recorded in any package.
GENSYM calls MAKE-SYMBOL (in effect).
2. Look up the name in a package. This way you get a symbol
that already exists. FIND-SYMBOL does this.
3. Look up the name in a package and create a new symbol if
it does not yet exist. The new symbol is "interned" in
the package so that subsequent lookups will find it.
INTERN does this. READ calls INTERN (in effect).
Since the symbols created by MAKE-SYMBOL and GENSYM aren't recorded
in any package (ie, aren't "interned"), you can't find them by looking
up their name. If (GENSYM "G") returns G0 and #:G0 is typed in, you
end up with two spearate symbol objects. There isn't any reasonable
way to make them be the same (EQ), nothing even tries to make them
the same, and we want them to be different anyway.
So much for EQ. EQL is the same EQ for most things, and in particular
for symbols. EQUAL is pretty much only a way to compare lists using
EQL on the leaves. EQUALP might have compared symbols by comparing
their names, but it doesn't.
CLtL2 is fairly clear about EQUAL and symbols. Page 107:
Symbols are compared as for EQ. This method of comparing symbols
can violate the rule of thumb for EQUAL and printed representations,
but only in the infrequently occurring case of two distinct symbols
with the same print name.
On the other hand, it's not obvious that this is how things are meant
to work, and it's understandable that you expected them to work differently.
-- jd
From: Mauro Gaspari
Subject: Terms in Lisp and Re: Uninterned symbols not eq, eql, or event equal?
Date:
Message-ID: <1992Dec2.221444.18638@cli.di.unipi.it>
In article <····@skye.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
|> #:name creates an uninterned symbol and (page 534) "every time this
|> syntax is encountered, a different uninterned symbol is created".
|>
|> From that we can conclude that (eq '#:a '#:a) ==> nil.
|> ...
|> Since the symbols created by MAKE-SYMBOL and GENSYM aren't recorded
|> in any package (ie, aren't "interned"), you can't find them by looking
|> up their name. If (GENSYM "G") returns G0 and #:G0 is typed in, you
|> end up with two spearate symbol objects. There isn't any reasonable
|> way to make them be the same (EQ), nothing even tries to make them
|> the same, and we want them to be different anyway.
|>
|> .....
|> On the other hand, it's not obvious that this is how things are meant
|> to work, and it's understandable that you expected them to work differently.
|>
|> -- jd
I would like to start a discussione here:
the problem is that most of the AI reasoning systems written in Lisp use
symbols as constant. As an example in the pubblic domain OPS
all the constants used inside the rules are interned in the package OPS.
This is a problem if you try to integrate it with a different
reasoning systems, because you need to transorm adequately the
data exchanged in order
to guarantee that all the constant and terms belongs to the right package.
This is because in general reasoning systems communicate
with primitives such as (prove query) or (assert fact) rather then
simple function calls.
For Prolog is different because a module (a concept similar to a lisp
package)individuate a particular space for names of predicates bu tot
for terms.
I do not want to discuss here the package structure of Common Lisp,
which could be very usefull in a functional framework.
My question is: why do not use uninterned symbols in order to
achieve a behaviour similar to the one of Prolog. i.e.
uninterned symbols could have the same role that terms
and constants have in Prolog:
If I assert in a module m p(a) and then I ask m:p(a)
I do not need to specify m:p(m:a) to succeed if I call the predicate
from another module.
This means in lisp that (eq 'foo::bar '#:bar) should return true
for every foo. Moreover: (eq '#:bar '#:bar) should also return true.
(i.e. if one of the symbols is uninterned the equivelence should be
"by name").
I know that this violate the Lisp definition of eq but I know also that
"eq" is antecedent to the definition of the package system for Common Lisp.
Mauro
--
------------------------------------------------------------------------
Mauro Gaspari, Dipartimento di Informatica, Universita' di Pisa, Corso
Italia 40, 56125, Pisa, Italy, phone: 39(0)50510263, fax: 39(0)50510226.
"To steal from one is plagiarism, to steal from many is research".
Wilson Mizner.
------------------------------------------------------------------------
From: Barry Margolin
Subject: Re: Terms in Lisp and Re: Uninterned symbols not eq, eql, or event equal?
Date:
Message-ID: <1flf59INNq8b@early-bird.think.com>
In article <·····················@cli.di.unipi.it> ·······@di.unipi.it (Mauro Gaspari) writes:
>My question is: why do not use uninterned symbols in order to
>achieve a behaviour similar to the one of Prolog. i.e.
>uninterned symbols could have the same role that terms
>and constants have in Prolog:
>
>If I assert in a module m p(a) and then I ask m:p(a)
>I do not need to specify m:p(m:a) to succeed if I call the predicate
>from another module.
>
>This means in lisp that (eq 'foo::bar '#:bar) should return true
>for every foo. Moreover: (eq '#:bar '#:bar) should also return true.
>(i.e. if one of the symbols is uninterned the equivelence should be
>"by name").
>
>I know that this violate the Lisp definition of eq but I know also that
>"eq" is antecedent to the definition of the package system for Common Lisp.
While EQ predates the package system, uninterned symbols are almost as old
as it is; MacLisp didn't have packages, but it did have first-class
obarrays and uninterned symbols. EQ is supposed to be the lowest level
equivalence test, which tests if two objects are the same, exact object (in
the case of boxed objects, it just compares the pointers).
If you just want an equivalence test that tells whether the symbols have
the same name, use STRING= (it automatically coerces symbols to strings).
But that's almost certainly not enough for your purposes. If you're using
these symbols in a reasoning system, they probably have data on their
property lists. Even if EQ were changed as you suggest, they'd still have
separate property lists. You can't have it both ways; either they're
separate, independent objects and have their own properties, or they're the
same object (which is the purpose of interning).
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
From: Mark Kantrowitz
Subject: Re: Terms in Lisp and Re: Uninterned symbols not eq, eql, or event equal?
Date:
Message-ID: <BywLn5.L4A.1@cs.cmu.edu>
In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
>But that's almost certainly not enough for your purposes. If you're using
>these symbols in a reasoning system, they probably have data on their
>property lists. Even if EQ were changed as you suggest, they'd still have
>separate property lists. You can't have it both ways; either they're
>separate, independent objects and have their own properties, or they're the
>same object (which is the purpose of interning).
I'd recommend using explicit hash tables, and write your own accessor
functions that will call some function to regularize the key before
accessing the hash table. Two good regularizing functions are: (1)
interning the symbol in the keyword package, or (2) using the
symbol-name.
--mark
From: Mauro Gaspari
Subject: Re: Terms in Lisp and Re: Uninterned symbols not eq, eql, or event equal?
Date:
Message-ID: <1992Dec10.192335.23409@cli.di.unipi.it>
Hi
Cause a problem of the Pisa
News server, I miss most of the answers
could you please post them again.
In article <············@cs.cmu.edu>, ······@cs.cmu.edu (Mark Kantrowitz) writes:
|> In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
|> >But that's almost certainly not enough for your purposes. If you're using
|> >these symbols in a reasoning system, they probably have data on their
|> >property lists. Even if EQ were changed as you suggest, they'd still have
|> >separate property lists. You can't have it both ways; either they're
|> >separate, independent objects and have their own properties, or they're the
|> >same object (which is the purpose of interning).
|>
Unfortunately I can read only this of your answer.
My problem is that my terms should be the same object but
they should be unified in different packages.
i.e the goal is to integrate different reasoning system
written from different persons,( the source code could be not
available).
Could you please post your message again?
|> I'd recommend using explicit hash tables, and write your own accessor
|> functions that will call some function to regularize the key before
|> accessing the hash table. Two good regularizing functions are: (1)
|> interning the symbol in the keyword package, or (2) using the
|> symbol-name.
|>
|> --mark
I can do this for my software, but....
what about software written from other peaple that
I would like to integrate in my system with minimal changes?
Mauro
--
------------------------------------------------------------------------
Mauro Gaspari, Dipartimento di Informatica, Universita' di Pisa, Corso
Italia 40, 56125, Pisa, Italy, phone: 39(0)50510263, fax: 39(0)50510226.
"To steal from one is plagiarism, to steal from many is research".
Wilson Mizner.
------------------------------------------------------------------------
From: Barry Margolin
Subject: Re: Terms in Lisp and Re: Uninterned symbols not eq, eql, or event equal?
Date:
Message-ID: <1gajm0INNego@early-bird.think.com>
In article <······················@cli.di.unipi.it> ·······@di.unipi.it (Mauro Gaspari) writes:
>My problem is that my terms should be the same object but
>they should be unified in different packages.
>i.e the goal is to integrate different reasoning system
>written from different persons,( the source code could be not
> available).
Yes, this is a problem with the Common Lisp package system. I've seen
other examples of it. Here's one that Kent Pitman mentioned to me a few
days ago, as justification for one of his comments during the dpANS public
review.
He suggested that Common Lisp standardize on a BOOLEAN type specifier,
which would be equivalent to (MEMBER T NIL). The reason is that many
applications and libraries would like to be able to recognize this type and
special-case it. The two he mentioned were Symbolics's Statice database
system (it can use a compact representation in the files for BOOLEAN
variables) and CLIM (the default presentation for a BOOLEAN would be "Yes"
or "No"). Currently, they each have a BOOLEAN symbol in their own
packages, and there's no way to integrate them easily when you're writing a
CLIM-based interface to a Statice database.
For this particular case we can just add this common symbol to the
COMMON-LISP package, so that it will be shared across most packages. I
don't know of a general solution for the problem, though. Making unrelated
symbols be EQ is not the solution, though.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
Typically when symbols are used as "keys" and the package of the symbol is
immaterial (i.e., the same named key could not be defined in a different
package), the symbol is placed in the keyword package. It is up to the
software to either read the key into the keyword package or convert a
symbol in another package.
If you find the package system getting in the way of accessing symbols you
think you need to use then either the package was not set up correctly
("interface" symbols not exported) or you are getting into someplace you
have no business being.
-ptr-