Issue: PRETTY-PRINT-INTERFACE (version 3)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 20 Mar 89 18:54:55 EST
    From: dick@wheaties.ai.mit.edu
    ....
    (Can you
    remind me of the issue of SIGPLAN notices that CLOS was described
    in?  Is that accurate?)  

SIGPlan Notices (ISSN 0362-1340)
Volume 23
Special Issue -- September 1988
ISBN 0-89791-289-6
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
call-next-method employed.

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.