[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Are isomorphic structures EQUAL?
- To: Jonathan A Rees <JAR@MIT-AI.ARPA>
- Subject: Are isomorphic structures EQUAL?
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Thu, 29 May 86 18:21 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <"860529142304.2.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>
Date: Thu, 29 May 86 14:23 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Date: Wed, 28 May 86 18:37 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: 11 Apr 1986 16:43-EST
What happens to implementations that want to represent structures
using plain old vectors? How will EQUAL distinguish vectors from
As Rees pointed out, such an implementation would not be legal.
I checked CLtL again and found (as far as I could tell) that it IS
permissible for an implementation to represent structures as vectors, or
as numbers, packages, symbols, or any other kind of object.
But it's not permissible to implement them as -plain- -old- vectors.
They have to be distinguishable, at least because the language requires
structures to print differently from vectors. It's true as far as I can
see that the language allows, after (defstruct foo bar), (subtypep 'foo
'vector) to be either true or false, on an implementation-dependent
basis, and (typep (make-foo) 'vector) to be either true or false. In
my implementation, for example, the subtypep is false and the typep is
true (I wonder if that's a bug?).
I would like to change the language so that the the type of structures
(whose DEFSTRUCT doesn't use :TYPE) is disjoint from other types.
Your arguments for this are good, but on the other hand this change would
be adding substantial new constraints on implementations, wouldn't it?
Probably the reason why CLtL is so coy about exactly how structures are
implemented is to maximize implementation freedom for some reason.