re: defstruct extensions

[goldman@vaxa.isi.edu]

The recently discussed extensions to DEFSTRUCT are reasonable and
needed improvements.  But I dissent from the proposal(s) for controlling
printing, which seem like they require the use of a sledgehammer to
crack an egg -- i.e., rebinding a special variable with dynamic effect
on printing of ALL structure instances (or even all instances of a
given class), including those embedded withing fields of other
instances, when what is wanted, if Corkill's example is
representative, is a finer control over a particular instance of printing.

In fact, it looks like what is wanted here is the CALL-NEXT-METHOD
ability of CLOS.  Think of PRINT-STRUCTURE as a generic operation,
with a method defined for STRUCTURE (which prints #<...>).  Providing
a print-function in a defstruct can then be viewed as a syntactic device
for defining a PRINT-STRUCTURE method for that specialization of STRUCTURE.

If there is sufficient need to resolve this problem prior to any
integration of CLOS and structures, I would favor a solution that at
least "feels" like this -- e.g., a special form (DEFAULT-PRINT-STRUCTURE)
(no arguments) that could ONLY appear lexically within a structure's
print function 
  (defstruct
	(employee
	 (:print-function
	  (lambda (employee stream print-depth)
	    (declare (ignore print-depth))
	    (cond ((and (not *print-pretty*) *print-escape*)
		   (DEFAULT-PRINT-STRUCTURE))
		  ;; Pretty printing requested
		  (t (format stream
			     "{Employee: ~A}"
			     (employee-name employee)))))))
    ...)


Alternatively, and less desirable in my mind, a function 
  (WRITE-STRUCTURE-DEFAULT structure-instance)
could be provided to ask for an arbitrary instance to be printed with
the default structure printer.

Neil