[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A few random I/O proposals
On Tue, 26 May 92 17:49:59 -0400, "Guillermo J. Rozas" <firstname.lastname@example.org> said:
[ Talking about sending output to strings. ]
> There are other possibilities.
> One of them would be to include the pair of procedures
> make-string-output-port and string-output-port-content.
> MIT Scheme has
> (with-output-to-string thunk)
> (with-output-to-truncated-string max thunk)
> with-output-to-string returns a string.
> with-output-to-truncated-string returns the cons of a boolean and a
> string. The boolean indicates whether the output was in fact
> truncated (true if it was truncated, false if it finished).
> It has string->input-port and with-input-from-port for input.
I think the former is probably a better idea, at least if there is
only going to be one way in the standard for sending output to
strings. I can imagine a situation occuring where somebody might want
to send output to two separate places at once, and
with-output-to-string doesn't cover that. At any rate, they're both
better than the possibilities I mentioned.
Minor points: I would call make-string-output-port open-output-string
instead, and string-output-port-content output-string-contents.
Output-string-contents should work on a port that has been closed. I
wouldn't want to include the with-output-to-truncated-string, and
would call string->input-port open-input-string instead. Also is
with-input-from-port a typo? Whether or not it is, having a generic
with-input-from-port (and with-output-to-port) might not be a bad idea
- much better than having to add an extra pair of procedures for each
new kind of port that a given implementation supports.
Concentrate on th'cute, li'l CARTOON GUYS! Remember the SERIAL
NUMBERS!! Follow the WHIPPLE AVE EXIT!! Have a FREE PEPSI!!
Turn LEFT at th'HOLIDAY INN!! JOIN the CREDIT WORLD!! MAKE me