extending DEFSTRUCT

[Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>]

    Date: 25 Oct 1987 08:47-EST 
    From: Rick.Busdiecker@H.GP.CS.CMU.EDU

    I also support the proposed extensions to structure handling.

	Date: Sat 24 Oct 87 15:16:08-EDT
	From: Dave.Touretzky@C.CS.CMU.EDU
    
	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
     unique names).

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.