[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PRETTY-PRINT-INTERFACE (version 3)
- To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
- Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
- From: firstname.lastname@example.org
- Date: Mon, 20 Mar 89 18:54:55 EST
- Cc: email@example.com, firstname.lastname@example.org, email@example.com
RE: your recent comments.
(1) Clearly, the right statements about length units need to be put in
the proposal. A note advising programmers to use explicit lengths as
little as possible also sounds like a good idea.
(2) I agree that it was a severe error to omit the funcional interface.
However, I also think it would be a severe error to omit the format interface.
(3) I understand why you would like to have define-print-dispatch
merged with the CLOS stuff. I will look into that. (Can you
remind me of the issue of SIGPLAN notices that CLOS was described
in? Is that accurate?) However, I think there may be problems.
First, although not particularly shown in the examples, I have
found very elaborate type specifies for printing things (e.g.,
including satisfies clauses) to be quite useful. In the proposal
note the use of the specifier (CONS (AND SYMBOL (SATISFIES FBOUNDP))).
Also note the use of priorities to disambiguate between overlapping
type specifiers. This is very important to get propper
defaulting---i.e. specifying how to print lists in general as well
as particular special forms. Maybe some inheretence things can
make that work in CLOS, but it is not clear to me.
Finally although it can certainly work, passing style of
printing arguments around does not appeal to me anywhere near as
much as multiple dispatch tables, because
when you write your first style, you have to set things up to
allow for more styles even if you never have more styles, or else
face a lot of work when you make a second style. It is also not
clear how this would all fit in with having a standard predefined
style that users can modify as they wish.
It seems to me that the pretty printer and CLOS just do not have
the same idea of what an object is, and that while CLOS primarily
has a quasi-static association of methods to objects, the pretty
printer wants to support rapid wholesale change. Given these
differences, unification may not work as well as one might hope.
(4) Your suggestions for improving the functional interface basically
sound good to me, however I differ slightly with a couple of them.
Combining the :stream and :var sounds like a good idea.
However, The :arg argument is not mandatory. It is not used in the
second example I sent around with the functional interface proposal.
I think that making :prefix, :per-line-prefix, and :suffix functions
is overkill. One can always use #. after all.
Changing the name of :from-start and :from-position and the argument
sounds fine to me.
note that ~/tabular-style/ etc. uses the format interface for
calling a function. Therefore it has already been implicitly
stated that tabular-style, fill-style, and linear-style, are
functions and what their arguments are. The definition of the
function linear-style is given as an example, and fill-style is
used as a function in another example in the original proposal.
Nevertheless, the functional interface part should note that they