Issue: STREAM-INFO (Version 6)

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

    Date: 10 Jan 89 12:58:22 EST (Tue)
    From: gz@spt.entity.com (Gail Zacharias)

    ...
    Then vendors who wish to do so, and who find a model such as presented
    by this proposal appropriate for their implementation, can provide the
    hooks as implementation-dependent extensions.

In practice, vendors don't do this. They each think their own theory of how
to provide the hooks is best, each insisting that other vendors' views of
the world are wrong. In the absence of an external agency (like ANSI) to 
force agreement, each feels entitled to disagree, believing it is right.
The advantage of a standard is that it enforces a little agreement.

    The simple fact is that this proposal is
    not universally implementable as stated, and loosening the restrictions would
    mean that you still cannot write a portable pretty printer, i.e. one that
    works correctly in all conforming implementations.

Technically, no, but for the universe of programmers we can reasonably
expect to sell to in the commercial community which ANSI influences, you
can do awfully good. If someone has a CL that supports Hebrew, let them
write their own pretty printer. I'd be surprised if they didn't plan to
do so anyway, so I doubt I'm asking them to do extra work. 

On the other hand, experience shows that Dick Water's very interesting
pretty printer did not reach all the target audiences that would have liked
to have it because he didn't have the time to adapt it to everyone's
idiosyncratic view of thew world, and they didn't have enough time to 
look over his code and realize how little work it would take to get it up
and running.

That's a real shame. This change comes to us from the CL user community
 from Waters himself, who tried to use those hooks which you assert
everyone has, and who found it too much work. I think it's our obligation
to try to address his need in some way if we can.

    A pretty printer which assumes fixed width fonts by default, but allows
    customization in ways appropriate for the text display model used by specific
    implementations, is a better solution to this problem than putting functions
    in the standard which are already known to be inappropriate for some existing
    display models.  I don't think it's the responsibility of the standard to
    provide hooks that give the illusion of portability to non-portable programs.

How about if we permit an ERROR-P argument which controls whether you signal
an error or just continue if you are in a variable width font and can't support
the indicated operation. That way you'd get the benefits of your supposed
improvement (which is that fixed-width fonts would work) and implementations
which supported variable width fonts and arbitrary addressing would not be 
penalized. In a few years, we could take some polls and find out if people
were mostly willing to set ERROR-P to T and let their application fall on the
floor when it ran up against a hard problem, or if they were mostly willing
to set ERROR-P NIL, so that their application would do the best it could do
rather than just falling apart in an obviously difficult situation. This would
have no illusion of portability since in reading about the ERROR-P argument and
deciding what to set it to, it would be clear to the programmer how the behavior
might vary between implementations.