On Sun, Aug 19, 2012 at 6:38 PM, Peter Bex <Peter.Bex@xs4all.nl> 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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports