On Sun, Aug 19, 2012 at 6:38 PM, Peter Bex <[email protected]> wrote: > On Sun, Aug 19, 2012 at 11:23:03AM +0200, Andy Wingo wrote: >> Hello, >> >> Is this implementation of call-with-input-file valid? >> >> (define (call-with-input-file filename proc) >> (let ((port (open-input-file filename))) >> (with-exception-handler >> (lambda (x) >> (close-input-port port) >> x) >> (lambda () >> (call-with-values (lambda () (proc port)) >> (lambda vals >> (close-input-port port) >> (apply values vals))))))) >> >> I think no, due to the language on p52 of the report: >> >> If proc does not return, then the >> port must not be closed automatically unless it is possible >> to prove that the port will never again be used for a read >> or write operation. >> >> I think we should specify that exceptional exits close the port, as the >> above implementation does. > > I've argued this point on several occasions before, but nobody listened :(
I'm sorry you got that impression. I've argued the same thing. You may not have gotten much feedback because we had discussed this already on the WG1 list. > With the current behavior users will need to remember to wrap each and > every call to call-with-input-file or with-input-from-file that *might* > cause an error (ie, probably ALL of them) in an exception handler. > This is very un-Schemely since it means the default behavior is simply > unusable. The problem is that you could have continuable exception, in which case it would be premature to close the port. Even with non-continuable exceptions, you could be dropped into a debugger where you might want to examine the port. There was discussion about having some sort of alternative to unwind-protect - it would _not_ be triggered simply by dynamic-wind (which is normal with continuations), but rather would only trigger on exceptions (I had tentatively proposed the name exception-protect). It would be presumptuous to have the call-with-* procedures use this automatically, for the above reasons, but users could call this themselves, and optionally we could have a safe-call-with-* procedure. The problem is this is straying into invention, so the general sentiment was to leave it to WG2. It's expected that implementations close files on gc, and a good implementation should gc when out of file descriptors as well. An alternate approach to more timely releasing of resources would be to add stronger guarantees about when gc occurs - again, an area of open research not yet ready for WG1. -- Alex _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
