Newsgroups: comp.lang.scheme
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: Alan@lcs.mit.EDU (Alan Bawden)
Subject: open-input-file [topics from hell, part 2]
Message-ID: <9104211907.AA25632@august>
Sender: alan@ai.mit.edu
Organization: The Internet
References: <CARLTON.91Apr20004133@husc10.harvard.edu>
Date: 21 Apr 91 19:07:37 GMT
Lines: 43

   Date: 20 Apr 91 04:41:33 GMT
   From: david carlton <carlton@husc10.harvard.edu>

   3) Have open-{input,output}-file return #f if the file doesn't exist.

[ I presume you don't really want open-output-file to return #f if the file
  doesn't exist! ]

   Currently, implementations are forced to signal an error in such a
   situation, which is ridiculous, since it makes it impossible to handle
   that situation, which is a fairly common one.

I agree that it is ridiculous that there isn't a way to handle that
situation.  But having open-input-file return #F isn't the solution.  For
one thing, inexperienced programmers would frequently forget to check the
return value.  

Also, you really do need finer control of exceptions.  People write
programs that need to distinguish between:

  o  The file does not exist in the specified directory.
  o  Some directory in the specified path does not exist.
  o  The file exists, but you aren't allowed to read it.
  o  You aren't allowed to read some directory in the specified path.
  o  The filesystem containing the file is unavailable (perhaps due to
     network lossage).

And for open-output-file things are worse because it involves possible
mutation of the filesystem.

I think ultimate solution is to have a condition system that can handle
exceptional conditions.  This may be another one of those things that you
can't really do until you have a coherent story to tell about dynamic
binding.  So forget the ultimate solution.

So how about giving open-input-file some additional arguments that specify
how it should behave in the exceptional cases?  Like an a-list of
"exceptions" and associated thunks -- if any of the exceptions occurs, the
associated thunk is (tail-recursively) invoked.  

This isn't a serious proposal, but something like it is clearly preferable
to the oft-suggested horror of simply having open-...-file return #F if
some ill-specified set of things go wrong.