This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.
Belated response... From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> Subject: Re: finishing output translating stream Date: Thu, 09 Jun 2005 07:51:07 +0200 > Now, this flushing business makes me a little concerned: What you're > proposing means my output data is different depending on when I call > flush. However, I always thought of this invariant as pretty > fundamental to what flush does---that it does not change the data. Hm, that is a reasonable concern. On the other hand, I regard 'flush' as to flush out any pending state in the I/O subsystem and start it over from a clean state---the state includes pending data in the buffer, or an unclosed escape sequence. If you want to keep the invariance, you wouldn't know flushing really flushes the buffer (Cf. <U+30AB> <U+309A> case). What's the use of 'flush', then? > It seems what you really should do to solve your problem is send a > message to the translator to insert the closing escape sequence into > the output stream, and have the *translator* flush after it has > encountered the message and written the closing sequence. You could > just use U+0003 (END OF TEXT) or something for that purpose. Would > this be reasonable? This is probably the logically cleaner solution, although I think it doesn't follow the convention. The application should be agnostic to the presense of translator stream. It used to be customary to call flush to tell I/O subsystem that "I'm done on the output for a while". Another practical (although slightly outdated) example: A command-line interactive application which prompts the user input. The cliche for the application to print the prompt would be something like this: (begin (display *prompt*) (flush-output-port)) If the terminal uses iso2022 encoding, and the prompt contains non-ASCII character---you do want to make sure the closing escape sequence is output before waiting for the user input. But you wouldn't know the user uses these settings. Do you suggest that all applications now should be written as this? (begin (display *prompt*) (display #\EOT) (flush-output-port)) I don't strongly insist my position, though, for there's usually workarounds for this problem. However, the translator can always discard the flushing message if it doesn't need it, so it doesn't hurt if flush-output-stream sends a special message to the translator. --shiro