> And as far as precedent goes, PP (or PRETTY-PRINT) is already
> widely disseminated through SLIB, if nothing else. There is plenty of
> precedent for alternate names for alternative I/O operations.

I'm not saying an implementation shouldn't define PP or PRETTY-PRINT
(in fact Gambit-C does exactly this).  This can easily be justified
by "convenience of debugging" reasons.  I typically use PP to insert
traces in my code or check the definition of a function from the REPL.

But there is a big difference between an API aimed at programming
applications (where being more verbose is not a real issue if it
allows you to access more features) and one aimed at debugging or
quick development.

> Separate procedures is much better.

So you wouldn't mind having to implement (and use) these procedures:

  write
  write-shared
  pretty-print
  pretty-print-shared
  write-with-radix
  write-shared-with-radix
  pretty-print-with-radix
  pretty-print-shared-with-radix
  write-show-hidden
  write-shared-show-hidden
  pretty-print-show-hidden
  pretty-print-shared-show-hidden
  write-with-radix-show-hidden
  write-shared-with-radix-show-hidden
  pretty-print-with-radix-show-hidden
  pretty-print-shared-with-radix-show-hidden

And what happens when you add one more feature?  Imagine the number
of SRFIs to write (and in your case review), the typos, the code
bloat, etc.

> I would *not* want all of the
> writes within a "parameterize"d block to suddenly get
> pretty-printed. There might be debugging messages buried in
> there. There might be writes going on to other ports. An out-of-band
> dynamically scoped write function (or read function) is too horrible
> to contemplate.

But this will not happen if you code your calls to write in this style:

  (parameterize ((write-shared #t)
                 (write-radix 16)
                 (write-prettily #t))
    (write X))

It is only if you start using parameterize in its full generality that
you can encounter such effects, but I would view this as a problem
with your coding style, not with the interface to "write".

Marc