[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PRETTY-PRINT-INTERFACE (version 3)
- To: email@example.com
- Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 20 Mar 89 21:39 EST
- Cc: firstname.lastname@example.org, cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: <8903202354.AA04220@wheat-chex.ai.mit.edu>
Date: Mon, 20 Mar 89 18:54:55 EST
remind me of the issue of SIGPLAN notices that CLOS was described
in? Is that accurate?)
SIGPlan Notices (ISSN 0362-1340)
Special Issue -- September 1988
ACM Order Number 548883
I don't know whether it's accurate, I haven't looked at it. I imagine
it is an exact copy of X3J13 document 88-002R, which is pretty close.
(3) I understand why you would like to have define-print-dispatch
merged with the CLOS stuff. I will look into that. 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.
So what you're saying is that you want to use type specifiers that have
unclear subtype/supertype relationships, and compensate for that by
using numerical priorities. I understand now. CLOS cannot currently
handle that through the normal parameter specializer mechanism, because
it requires clear subtype/supertype relationships from the type
specifiers alone. On the other hand, one could make a form of method
combination that did the same thing as define-print-dispatch, but that
would be going through the back door. On the third hand, some of the
applicability testing could be moved into the body of the method and
At this point I don't know what to say; expediency and elegance seem
to be in direct conflict. Maybe someone else has an idea. I certainly
will not block the thing for this point of esthetics, but it does raise
a red flag for me that something somewhere is inadequate.
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.
I think if you think about this harder you'll realize that dispatch tables
and style-of-printing arguments are isomorphic and differ only in some
minor internal implementation details.
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.
I think this is a non-issue, but the real problem is what you said above
complex type specifiers.
(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 don't recall seeing any examples of the functional interface. Let me
ask, how frequently is the :arg argument omitted? If it's omitted very
infrequently, it would be better to supply an explicit nil in those cases
than to say :arg in all the rest of the cases.
I think that making :prefix, :per-line-prefix, and :suffix functions
is overkill. One can always use #. after all.
No, the issue is a function that decides at run time what to output, rather
than having a canned string. Whether the string appears in the source or
is generated at compile time is of no moment. But if you don't want to
put in the extra flexibility, I won't complain, I don't have a specific
use for it in mind, I only proposed it on general principles.