Re: Issue: STREAM-INFO (Version 4)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 29 Jun 88 23:32:43 PDT
    From: masinter.pa@Xerox.COM

    How 'bout just making it explicit that this things are intentionally left
    undefined, with some of the reasons you gave?

    I'm a little leary of adding a function where the requirements on the output
    values are not spelled out. Is the width of "froboznick" guaranteed to be the
    sum of the widths of "frob" and "oznick"? Greater than the width of "frob"? Of
    "foo"? What about kerning?

Dick spelled out the requirement. He doesn't need an algebra on these values.
The only need he has, and it's quite legitimate, is to ask "If I were to output
this, where would I end up." If there's something that will, in the same units,
tell him where the margin is, he can at least know if he's passing an interesting
boundary.

Kerning is not really relevant. Either the implementation looks at kerning when
deciding if a line is too long or it doesn't. The thing which returns the margin
position and the thing which returns the string width can easily conspire to do
the right thing without prejudice to whether kerning is involved.

Dick could have just as well asked for a primitive that would have said
(OUTPUT-FITS-P string stream) and returns T or NIL saying whether the string will
fit on the stream without running into the margin, but that would have been so
limited to his application that it would have served no useful extension purposes
in implementations that did want to extend it.

    If we can't guarantee anything about these functions, can programmers really
    write portable programs? Or would a hack with #+ and #- be more honest?

The issue is not honesty. The issue is one of codifying existing
practice. Dick Waters has done a lot of really interesting work on
pretty printers over the years. That work has been of tremendous benefit
to the Lisp community.  In Maclisp, he could essentially tell where the
end of the line was. We took away that capability in Common Lisp.  In
Common Lisp, you can't even clear the screen. I personally think that
was ridulous, and I'm surprised that the user community put up with it.
But the world was more complicated with fancy displays and fancy fonts
and all, and people were tolerant for a while.

But we've had our time to play and it's really time we came up with
something useful so people can get on with their work if at all
possible.  The set of primitives proposed is a subset of what is in use
on a major Lisp workstation and it has been demonstrated to be useful.
If it has problems to do with kerning (things have to be rounded off),
output will look no stupider than it will look if we don't allow people
to have pretty printed output at all. More likely, it will work just
fine because most applications are very fault tolerant -- in the worst
case, you might get some line wraparound and yucky looking typeout. But
you'll get line wraparound a LOT more in portable programs if you offer
people no way at all to detect the edge of the line.  We should just warn
people that the process is heuristic and people who are building weapons
systems or real time medical systems can avoid using it.

Common Lisp is not an exercise in doing everything right the first time.
It is an exercise in trying to satisfy the commercial needs of a lot of
Lisp users for the next few years. My condition system has its problems,
too, but the important point in both cases is that it is an improvement
over what is there if you don't have it. Sometimes when you don't fully
understand an issue, you just have to go with your best guess and be
prepared to have problems result.  As embarrassing as it is to have your
mistakes noticed later, it's sometimes better than not taking any action
at all.  And after using for a few years, you'll have a user community
who can make informed decisions about whether they like what they got
and what they want next.  If you don't offer them anything at all, then
in five more years you'll have no one who's any more informed on the
issues than you have now and you'll end up having to make the same
arbitrary decision as you're making now.

Also, this problem is not like characters or pathnames where we are
forcing a representation. If necessary, a particular vendor with special
needs can have these primitives can work completely independently of how
the rest of system represents width, position, etc.  on the screen -- or
it can just return NIL all over the place saying it's not willing to
play the game.