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.
I think POSIX stdio guarantees the program termination (either by returning from main() or calling exit(2)) causes stdout flushed, so the following program always print "Hello" (without newline) to the stdout. #include <stdio.h> int main(int argc, char **argv) { printf("Hello"); return 0; } Although R5RS doesn't say anything about it, it is natural for programmers with POSIX background to expect the same behavior in the following program (assuming srfi-22): (define (main args) (display "Hello") 0) This behavior is automatically achieved if the implementation is using system's buffered I/O directly to implement ports. The srfi-68 author has suggested the reference implementation to be a drop-in replacement for existing implementations, but it is not obvious how such implementations guarantee the "flush-on-exit" behavior. It is a practical issue. When I switched Gauche's I/O system from stdio to own buffering, I overlooked this problem and got reports that existing programs had broken, and I had to implement a weak pointer table to manage opened ports. (Object finalization on the program termination may or may not save this. If finalizers run with considering dependencies, the port can be finalized before underlying streams and writes, so it's OK. However, it is generally difficult to run finalizers strictly observing dependencies (e.g. there can be a circular reference) and the implementation may choose to run finalizers without ordering.) It's fine that srfi-68 leaves this issue open to the implementations. However, claiming the reference implementation as a practical replacement to the existing implementation's I/O layer could be an overstatement. Considering issues like this or port-locking (*1) or asynchronous finalization (*2), I imagine it is extremely difficult to provide even reasonably working code as a single universal reference implementation. I do see the usability of customizable ports, but srfi-68 seems too large for me to have confidence that it surely work under different implementations. Maybe it's a good idea to split it to smaller modules, each of which can be easily implemented by different implementations and can be confirmed it works. (*1) http://srfi.schemers.org/srfi-68/mail-archive/msg00042.html (*2) http://srfi.schemers.org/srfi-68/mail-archive/msg00021.html --shiro