[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Rick.Busdiecker@cs.cmu.edu
- Subject: extending DEFSTRUCT
- From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
- Date: Sun, 25 Oct 87 21:31 EST
- Cc: Dave.Touretzky@C.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU
- In-reply-to: <562168063/rfb@H.GP.CS.CMU.EDU>
Date: 25 Oct 1987 08:47-EST
I also support the proposed extensions to structure handling.
Date: Sat 24 Oct 87 15:16:08-EDT
When *PRINT-STRUCTURE* in NIL:
I think a slightly better name is *PRINT-STRUCTURE-CONTENTS*.
(We've had this for a couple years).
Most of us find this has to be NIL in order not to be innundated
with useless internal details of the structures we look at.
(The #<...> representations are designed to provide what information
you need at a glance).
Generally, CL fails to distinguish between PRINT/READ as communication
between programs (in which case, you either want to bind all the flags
to standard, known values, or ignored totally), and communication with
the user or programmer, in which case you want the flags set for maximum
usability. #S syntax is clearly an example where utility for programs
was chosen over usability for programmers.
defstructs with their own print functions will use them
defstructs without their own print function will print in the #<> notation
Is there really a standard for #<> notation? If so, what is it and
where is it defined? If not, perhaps we should define a default #<>
notation such as #<name-of-structure-type>.
The standard is that it signals an error (see pg 360 of CLtL).
What CLtL doesn't say, but should, is that:
1) The #< should be balanced with a >.
2) There are certain recommended higher conventions to be followed:
a) The type should be given first. This is not necessarily
what TYPE-OF will return, but it should be descriptive
and non-confusing to the user. (This means it should
probably be a type acceptable to TYPEP, of which this object
is a member). The structure type name is the default.
b) Named objects should, where possible, follow their type
with their name.
c) Other descriptive information may be included, in a user-determined
(but brief) format.
d) Where it is desirable to distinguish different instances of
the same type of object, which may otherwise print the same,
the last thing printed before the closing ">" should be a
unique-ID. (On our system we use the octal address by default).
This should generally be omitted when there is no difficulty
distinguishing objects on sight (for example, objects with
As you can see, these are conventions designed to make things easier
for the programmer looking at these objects while debugging, and
not something that some program or other rigid-thinking entity
will look at.