[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PRETTY-PRINT-INTERFACE (version 3)
- To: Guy Steele <gls@Think.COM>
- Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Sat, 18 Mar 89 01:32 EST
- Cc: email@example.com
- In-reply-to: <8903152049.AA03416@verdi.think.com>
In general I like this. Certainly I like the idea of having a
standardized interface for extending the pretty-printer, and I believe
that this particular pretty-printer is based on a good underlying
theory, certainly the best theory that I have seen. However, I don't
think this is ready to go into the standard in its current form. Some
of these comments are on the programmer interface, others are just on
the way the proposal is presented.
I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation. It's not even clear that margins,
indentation, and tabulation can't be measured in three different
units. Analysis of the examples suggests that the units are
assumed to be characters and all characters are assumed to be the
same width. This is not an implementation-independent assumption.
In any case the proposal has to be specific about the units. I
would prefer something that seamlessly accomodates variable-width
characters, but don't have enough experience with pretty-printers
to propose anything myself.
I would like to be able to vote on the FORMAT-based interface and
the functional interface separately.
I would like to see the DEFINE-PRINT-DISPATCH mechanism recast in terms
of DEFMETHOD and a PRETTY-PRINT-OBJECT generic function. If DEFMETHOD
is deficient and unable to provide all the necessary features, I think
we need to know that before it's too late to amend CLOS. I don't see
any problems myself, other than the need to replace the funny extension
to the CONS type-specifier with passing of the CAR of the CONS as a
separate argument so an EQL parameter specializer can be used.
I'd like to suggest some improvements to the syntax of
WITHIN-LOGICAL-BLOCK, based on Symbolics experience with similar macros:
Instead of separate :STREAM and :VAR keywords, it works better to have
only a :STREAM keyword, whose value must be a symbol. This symbol
is evaluated to get the stream, and also is bound around the body to
a (possibly new) stream. This simplifies the syntax and avoids the
risk of accidentally writing to the wrong stream.
Defaulting to *STANDARD-OUTPUT* and handling T and NIL is correct here
(:STREAM NIL means *STANDARD-OUTPUT* is the variable that gets bound.)
Since the :ARG argument appears to be mandatory, it should be a
required argument preceding the keyword arguments. This would also
eliminate the meaningless keyword name for this argument.
It would be nice if the :PREFIX, :PER-LINE-PREFIX, and :SUFFIX
arguments could be functions as well as strings, to allow more control
over the printing of this information. That's not essential, but it
would for example make it easier to print special characters.
The :FROM-START and :FROM-POSITION values for KIND in LOGICAL-BLOCK-INDENT
are too easily confused. I suggest renaming them to :BLOCK and :CURRENT
and renaming the argument to RELATIVE-TO.
The functional interface is missing equivalents for the
~/TABULAR-STYLE/, ~/FILL-STYLE/, and ~/LINEAR-STYLE/ features.
I think it's better to provide these as predefined functions
than to make the user define them himself.