[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

more questions

I have not been able to find (clear) answers to these questions in the manual.
Clarification is requested.

* What happens if the type name in a DEFTYPE or DEFSTRUCT is the name of an
existing type (either primitive or user-defined)?  Is redefinition allowed or
prohibited, and in what circumstances?

* What happens in a DEFSTRUCT if two slots have the same name?  Is it an
error, or is the extra slot definition ignored?

* What happens in a DEFSTRUCT if a slot has the same name as an inherited
slot?  Is it an error, is the new slot definition ignored, are the two slot
definitions "merged", or does the new slot "shadow" the inherited one?

* The definition of *PRINT-CIRCLE* only says that the printer "will endeavor"
to detect cycles.  How hard must the printer try?  Is an implementation that
totally ignores *PRINT-CIRCLE* correct?

* Are cycles involving structures (DEFSTRUCTs) handled by *PRINT-CIRCLE*?  If
so, how do DEFSTRUCT :print-functions interact with *PRINT-CIRCLE*?

* May an implementation impose a fixed upper bound on the length of a symbol
name?  If so, is there a minimum such bound?  Similar questions can be asked
regarding the sizes of strings, vectors, and arrays, and the possible
interrelationships among such limits.  (It is important to make our
assumptions explicit, as an implementor whose background is in conventional
programming languages might not share these assumptions.  Ideally, I would
say that no fixed limit other than available free storage can be placed on any
of these sizes.)

* Must (EQ (SYMBOL-NAME 'FOO) (SYMBOL-NAME 'FOO)) be true, or may the function
SYMBOL-NAME return a newly created copy of the name string each time it is
called?  (My reading of the definition is that there is a unique print name
string for each symbol and that SYMBOL-NAME returns it; others have come to a
different conclusion.)

* DEFSTRUCT does not create named functions for altering components of a
structure, but instead arranges to make SETF do "the right thing".  Does this
mean that the user cannot TRACE structure alteration or control the use of
inline code for structure alteration (which might affect how the debugger
describes the state of a computation)?  (The general question: is not having
named update functions for generalized variables really such a good idea?)

Alan Snyder