Re: [Scheme-reports] valid implementation of call-with-input-file?

[Peter Bex <Peter.Bex@x>]

On Tue, Aug 21, 2012 at 12:55:39PM -0400, Aaron W. Hsu wrote:
> Andy Wingo <wingo@x> wrote:
> > I think we should specify that exceptional exits close the port, as the
> > above implementation does.
> 
> This isn't actually a good implementation. Exceptions do not constitute, 
> and should not be equivalent to, non-local exits that can never return. 
> Exceptions may be continuable, and in the case of a continuable exception, 
> we may return and do some more work. In this case, closing the port 
> is incorrect.
> 
> Even in the case where we have a non-continuable exception, it may be that 
> we can try to restart the computation in certain cases, and we should not 
> close the port in this case either. 

The same is true for capturing the continuation during
with-input-from-file's dynamic extent and then invoking it after it has
returned, but you never hear anyone going on about *that* being broken.
I think you're measuring with two standards here.

There's no reason to make a distinction between "normal" and
"exceptional" exits.

> In other words, you cannot really guarantee that you won't want the port 
> open in the general case, so you should not close it.

But it *is* closed, upon a normal "return" of the procedure.  You can't
seriously be saying that this has always been broken and should be
reconsidered as well?

The pragmatic thing to do is to close the port when the procedure
returns, and that's what previous reports have done.  Now that exceptions
are added to the standard, I think it only makes sense to specify that
*at least* non-continuable exceptions are treated the same way as normal
exits.

> It is easy enough to create a macro to encapsulate an use case that you
> want, if you know that you only use that style of programming,
> and all your exceptions will never continue the computation.

This effectively relegates the standard procedure to a "too low-level"
status which will mean programmers need to invent their own libraries
just to work around this.  Of course, different implementations will
do it in different ways (or not at all).  Way to go, standards committee!

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
							-- Donald Knuth

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports