[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE , Version 3
- To: cl-cleanup@sail.stanford.edu
- Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE , Version 3
- From: goldman@vaxa.isi.edu
- Date: Fri, 13 Jan 89 09:57:56 PST
- Cc: goldman@vaxa.isi.edu
- Posted-date: Fri, 13 Jan 89 09:57:56 PST
- Sender: goldman@vaxa.isi.edu
The reason I do not support this proposal is twofold:
1) It does not go far enough -- in particular, it does not enable
the print function of a structure to examine the structure instance
and conditionally "hand off" to the printer for the included (more general)
class.
2) I do not see why a more specialized class should need to directly invoke
the most general (#S) printer. I notice that no one has suggested
CLOS have an alternative to NEXT-METHOD called MOST-GENERAL-METHOD. If
there is something particular about the #S syntax, I would rather simple
have an advertised CL function PRINT-#S-STYLE(structure stream depth).
I would like to see the :print-function for defstruct beefed up as follows:
(defstruct (struc (:print-function (lambda () <body>))) ...)
When a lambda expression is used as the print-function, its body may
invoke the zero-argument lexical function (or macro, I don't really care)
(NEXT-PRINTER) to invoke the next most general printer on the
same structure, stream, and depth. The #S printer is the most general --
that is, if a structure class C does not include, directly or indirectly,
any class with its own print-function, then (NEXT-PRINTER) from
C's print function will invoke the #S printer. The purpose of this protocol
is to allow a print function to inspect the particular structure and
choose to delegate printing authority to a more general printer if the
structure does not meet its criteria.
I recognize that my proposal only provides this functionality to
print-functions specified via lambda expressions, rather than
symbols. But I haven't yet encountered a situation where I
would prefer to use a symbol rather than a lambda expression, so
that doesn't bother me. Obviously the protocol permits a programmer
to write his print-function as
(lambda (x s d) (my-printer x s d #'next-printer)
or, if NEXT-PRINTER is a lexical macro rather than a lexical function,
(lambda (x s d) (my-printer x s d #'(lambda () (next-printer))))
so you can indirect all the interesting logic through a named function
anyway.
another 2cents worth,
Neil