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.
Shiro Kawai <shiro@xxxxxxxx> 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