Section 3.2.4.2.2 defines the 'similarity' relation on various data
structures. For CONS objects, the definition is:
Two conses, S and C, are similar if the car[2] of S is similar
to the car[2] of C, and the cdr[2] of S is similar to the cdr[2] of C.
But consider two cons objects, each of whose car and cdr is itself.
Are these objects similar? The definition does not say.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Section 3.2.4.2.2 defines the 'similarity' relation on various data
> structures. For CONS objects, the definition is:
>
> Two conses, S and C, are similar if the car[2] of S is similar
> to the car[2] of C, and the cdr[2] of S is similar to the cdr[2] of C.
>
> But consider two cons objects, each of whose car and cdr is itself.
> Are these objects similar? The definition does not say.
The same would apply to any circular list like #1=(1 2 3 . #1#).
At the beginning of 3.2.4, it says:
# This section defines the concept of similarity which relates objects
# in the evaluation environment to the corresponding objects in the
# run-time environment.
And in 3.2.4.4:
# Objects containing circular references can be externalizable
# objects. The file compiler is required to preserve eqlness of
# substructures within a file. Preserving eqlness means that
# subobjects that are the same in the source code must be the same in
# the corresponding compiled code.
So, if it is allowed to do that, and if the whole purpose of
similarity is only to describe the relationship between the objects we
have at compile time and those we're going to get at run time, I'd say
this means that your cons cells /are/ similar :-)
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xEEFBA4AF