[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new function or modify read
> 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
> Separate procedures is much better.
So you wouldn't mind having to implement (and use) these procedures:
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
> 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)
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".