Shiro Kawai <xxxxxx@lava.net> writes:

> 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.

You took my statement out of context: The "drop in" referred to a
system where ports are already implemented.

> (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.)

Another approach is to iterate flushing until you get no more
output, which is what Scheme 48 does.

> 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.

Sure.  The specification is carefully organized in sections so as to
make such a split possible.  In fact, the reference implementation is
organized as layered modules in accordance with the division in the
draft.  The main reason I didn't write three SRFIs is that I wanted to
develop them in close tandem, not because I disagree with the
organizational principle.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla