eliot@phoenix.Princeton.EDU (Eliot Handelman) (03/30/89)
Should (TYPEP OBJECT TYPE) test first whether TYPE is the name of a structure, or whether it has an explicit type attached to it via DEFTYPE? For example: >(defstruct (quux (:type list) :named) x y) QUUX >(deftype quux () '(satisfies quux-p)) QUUX >(setq q (make-quux)) (QUUX NIL NIL) (typep q 'quux) In KCl ==> NIL In Lucid 2.2 ==> T KCl says no because it knows that QUUX names a structure, and so it passed q off to its special structure-handling procedures where it determined it to be of tyoe cons. This doesn't seem right to me in the case of named structures. What should happen?
barmar@think.COM (Barry Margolin) (03/31/89)
In article <7480@phoenix.Princeton.EDU> eliot@phoenix.Princeton.EDU (Eliot Handelman) writes: >Should (TYPEP OBJECT TYPE) test first whether TYPE is the name of a structure, >or whether it has an explicit type attached to it via DEFTYPE? I don't think it is supposed to be valid to define a type both via DEFSTRUCT and DEFTYPE. However, CLtL doesn't seem to say this explicitly. But since it doesn't say how they are resolved, either, it's obviously not intended to be portable. >>(defstruct (quux (:type list) :named) x y) This form isn't supposed to define a type QUUX. The description of the :TYPE option on p.314 says that specifying :TYPE "prevents the structure name from becoming a valid type specifier." >>(deftype quux () '(satisfies quux-p)) >QUUX >(typep q 'quux) >In KCl ==> NIL >In Lucid 2.2 ==> T >KCl says no because it knows that QUUX names a structure, and so it passed >q off to its special structure-handling procedures where it determined it >to be of tyoe cons. This doesn't seem right to me in the case of named >structures. What should happen? Since the DEFSTRUCT shouldn't make QUUX a type specifier, I agree with you that KCL is incorrect. Had you not specified :TYPE, I think your code would be invalid. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar