I understand that an implementation is allowed to copy characters (and
numbers) whenever it feels like[1] it which means EQ may not return true
for two characters that seem to be the same. That is even (eq x x) is
not guaranteed to be true if x is a character.
Is it also the case that there is no way to make two character
"objects" with the same char-code and implementation-defined
attributes that are guaranteed to be different objects, i.e. not EQ?
-Peter
[1] From EQ dictionary entry:
An implementation is permitted to make ``copies'' of characters and
numbers at any time. The effect is that Common Lisp makes no
guarantee that eq is true even when both its arguments are ``the
same thing'' if that thing is a character or number.
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
> I understand that an implementation is allowed to copy characters (and
> numbers) whenever it feels like[1] it which means EQ may not return true
> for two characters that seem to be the same. That is even (eq x x) is
> not guaranteed to be true if x is a character.
>
> Is it also the case that there is no way to make two character
> "objects" with the same char-code and implementation-defined
> attributes that are guaranteed to be different objects, i.e. not EQ?
But you can make two objects that are "characters" with the properties
you want, keeping a cache of boxed characters [ (cons char nil) or
(make-array '(1) :initial-element char)]. Then you can eq the boxes.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.