Issue: STREAM-INFO (Version 4)

[dick@wheaties.ai.mit.edu (Richard C. Waters)]

      Does your pretty printer depend crucially on the equality in
    properties (3) and (6), or can they be relaxed to inequalities

       (3) (<= (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
	       (OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))

Several points here;  First, the pretty printer does crucially depend
on the fact that if there is any significant inequality, then it must go
the other way.  I.e.

 (=> (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
     (OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))

The pretty printer has to be able to make a guaranteed pesimistic
prediction of what the output position will be without actually
printing anything.  If the inequality went the way you suggest, I
could not be sure that printing the string would not go off of the end
of a line.
  Second, having it be an equality is not TOTALLY crucial, but without
it, I would have to query the stream for the resulting output position
every time I sent a string to it.  With the equality, the stream
almost never has to be queried---A significant saving in time.
  Third, it is true however, that it is not going to make any
difference to the pretty printer if the equality is off slightly.  The
most aesthetic way for an implementation to deal with this case is to
make the horizontal unit returned by the functions course rather than fine.
  Fourth, if there is a fear that the property above would make it too
hard to implement STRING-WIDTH, then one might only require that the
property hold if the string contains standard characters, and allow
implementations to vary as to how close they come to the ideal in
general.  (Note that with this weak a restriction, and assuming a
fixed width font, the function STRING-WIDTH could be implemented
merely as LENGTH.  This is the way the pretty printer works now, and
it doesn't seem to be causing any problems.)
  Fifth, the bottom line here is that pretty printing will work better
or worse based on how accurately STRING-WIDTH is implemented.
However, there is nothing for the pretty printer to do, but simply
assume that the information is accurate.

       (6) (<= (STRING-WIDTH (CONCATENATE 'STRING X Y) S)
	       (+ (STRING-WIDTH X S) (STRING-WIDTH Y S)))

Here, the comments are much the same.
  First, this time the inequality as stated is in the proper direction.
  Second, having the inequality is not totally crucial, but it
significantly reduces the number of times OUTPUT-POSITION and/or
STRING-LENGTH have to be called.
  Third, it is not going to make any difference to the pretty printer
if the equality is off slightly.
  Fourth, note that the equality is only required when the string
contains standard characters.  If a fixed width font is in use, this
is consistent with implementing STRING-WIDTH as length.

I strongly suggest supporting both of the above as eqaulities at least
for standard characters.  Since in the fixed width font case this is
trivial to do, I see no argument against it.

			Dick