Issue: FORMAT-PRETTY-PRINT (version 2)

[Dan L. Pierson <pierson%mist@multimax.ARPA>]

Issue:         FORMAT-PRETTY-PRINT
References:    FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
               WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category:      CLARIFICATION
Edit history:  Version 1 by Pierson 3/4/88
    	       Version 2 by Pierson 5/24/88 (fix name typo)
Status:        For Internal Discussion

Problem description:

The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively.  The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.

Proposal (FORMAT-PRETTY-PRINT:YES):

The ~A and ~S FORMAT operators (and the ~B, ~D, ~E, ~F, ~G, ~$, ~O,
~R, and ~X FORMAT operators when they encounter a non-numeric value)
are required to treat all *PRINT-foo* variables the same as PRINC and
PRIN1 respectively.  [[ Yes, this is a bit broader than the title, but
if we're going to clarify this we might as well do the whole job.  I
don't think any of the other variables are likely to be controversial.]]

Test Cases/Examples:

(LET ((TEST '(LAMBDA (X)
               (LET ((*PRINT-PRETTY* T))
	         (PRINT X)
		 (FORMAT T "~%~S " X)
		 (TERPRI) (PRINC X) (PRINC " ")
		 (FORMAT T "~%~A " X)))))
  (FUNCALL TEST TEST))

This should print four copies of the above lambda expression.  The
first pair should appear identical and the second pair should appear
identical.  The only difference between the two pairs should be the
absence of string quotes in the second pair.  Note that this example
won't work as written if the proposal FUNCTION-TYPE:STRICT-REDEFINITION
is accepted. 

Rationale:

FORMAT should interact with the *PRINT-foo* variables in a predictable
way.  This proposal is one of the two simplest possible definitions
and provides the most flexibility to the user.

Current practice:

Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.

Cost to Implementors:

While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications.  How does a pretty-printing ~A
interact with MINCOL, etc?  How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?

Cost to Users:

Truely portable code shouldn't be affected because existing
implementations are inconsistent.  Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.

Cost of non-Adoption:

The interaction of FORMAT and the *PRINT-foo* variables (especially
pretty printing) will remain undefined.  This will continue to make
portable Common Lisp programming harder than it need be.

Benefits:

Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.

Aesthetics:

The interaction between two related parts of output will be clarified
in a simple way.

Discussion:

Pierson feels that this is important because the ease of implementing
major system interfaces with FORMAT can unintentionally lead to less
flexibility for the user compared to an old-style PRIN1/PRINC/TERPRI
implementation.  This clarification would generate some up front work
but would make it harder for people to accidentally create restrictive
interfaces.