more questions

[Rob MacLachlan <RAM@CMU-CS-C.ARPA>]

    Date: Thursday, 20 September 1984  18:51-EDT
    From: AS%hplabs.csnet at csnet-relay.arpa
    To:   Common-Lisp at su-ai.arpa
    cc:   AS at csnet-relay.arpa
    Re:   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?

  I would say that except for redefining a DEFTYPE with another
DEFTYPE, all of these should be errors.  Permitting any of these things
would add complexity without adding any power.


    * 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*?

  It is clearly possible, and not even very difficult, to detect
cycles, thus I see not reason why the printer shouldn't do it.  All
you have to do is enter every object printed in a hashtable, clearing
the hashtable at every top-level call to Print.  Structure print
functions add no substantial degree of complexity to this.  Print
simply needs to detect when it has been called from a print function,
and not clear the hashtable in that case.  Of course if the
print-function itself breaks due to circularity in the structure,
there is nothing that can be done.


    * 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.)

  There is Array-Total-Size-Limit, whose minimum value is 1024.  Most
likely, the real limit on total size will be different for different
types of arrays, but this limit should be the minimum.  Since for
symbol functions no type specification is given for the pname other
than that is a string, then any legal string must work.  This would
mean that the least limit on pname length would be 1024.


    * 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.)

  I would say that this should be left up to the implementation, since
requiring this would constrain the implementor without buying any power.


    * 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?)

  I would say that it is currently clearly the case that setf methods
cannot be traced.  If function specifications are added to the
language, then they could be used to fix this problem.  Since a setf
method has in the general case the semantics of a macro, it doesn't
seem possible to declare a setf method not inline.

  Rob