Issue: PRETTY-PRINT-INTERFACE (version 3)

[dick@wheaties.ai.mit.edu]

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
    are functions.