A few random I/O proposals

[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. The Unix
(#f) solution is implementationally simpler for the OS writer, which
means the OS is more likely correct or bug-free, but user code
sometimes breaks (if you ever experienced a core dump after hitting ^C
to a Unix program and then continuing, you found a system call whose
flag was not checked). If you do the right thing, the implementation
is difficult and likely contains bugs.

I watch your debate with interest.

By the way, this style

(define (open-input-file str)
  (or (open-file str OPEN_READ)
      (and (procedure? could-not-open) (could-not-open) #f)
      (error "OPEN-INPUT-FILE couldn't find file " str)))

was popular in the early 1970's at MIT (when some people thought it
produced better code than the equivalent COND). In the late 1970's
through the 1980's it was considered goofy. Is it now cool again?

			-rpg-