[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: AS%hplabs.csnet@CSNET-RELAY.ARPA
- Subject: more questions
- From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
- Date: Sun, 23 Sep 1984 12:03:00 -0000
- Cc: AS@CSNET-RELAY.ARPA, Common-Lisp@SU-AI.ARPA
- In-reply-to: Msg of 20 Sep 1984 18:51-EDT from AS%hplabs.csnet at csnet-relay.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
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
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.