A few random I/O proposals

[Scott L. Burson <gyro@drums.reasoning.com>]

   Date: Wed, 27 May 92 15:23:46 PDT
   From: rpg%inferno@lucid.com (Richard P. Gabriel)

   I hope you folks realize you are debating my primary example in
   ``Worse is Better.'' That is, is it better for the OS to return a flag
   from a system call that indicates whether the call succeeded, or is it
   better to go to great lengths to make sure it succeeds, backs out, or
   signals an error properly? For the pc-losering problem, Unix returns a
   flag, and ITS/WAITS/any-proper-OS completes or backs out.

Well, but it's not quite exactly the same thing.  In the case of pc-losering,
it is possible for the OS to do the right thing with no cooperation whatever
from the user program and without affecting it.  In the case of an error in
opening a file, on the other hand, the user program is going to have to deal
with the condition one way or another, and the only question is how to provide
for that.

More substantively (Dick will hate this! others might too):

Since Scheme has no error/condition system yet, and since having OPEN return #f
for failure is an imperfect solution for reasons that have been well covered,
how about having OPEN accept a failure continuation argument?  I know this is
not a popular sort of proposal, but I really don't understand why not; and
given that the alternatives are not real appetizing either, I think it should
be kept in mind as a candidate for, if nothing else, the least bad choice.

For those who don't know, Dick will hate this because it almost mandates the
use of CALL/CC, which he repeatedly proposes banishing from the language.  It's
curious to me that neither his proposal nor proposals for explicit failure
continuation arguments have historically gotten much support.  If the community
is really so reluctant to use CALL/CC on a daily basis, is it possible Dick is
right that it shouldn't be there in the first place?

-- Scott