[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

What I want in R^5RS



   > Should DELETE-FILE return an indication of success or failure?

   I don't care.  Perhaps more important is the question of whether or
   not `an error is signalled' if the specified file does not exist.  I
   would not be offended by:
     (DELETE-FILE <name> . <bool>)
   where the optional boolean argument indicates whether or not one wants
   an error signalled if the specified file does not exist.  I.e.
   (delete-file "random" #t) would complain if "random" did not
   exist, but (delete-file "random") and (delete-file "random" #f) would
   not. 

   Other suggestions?

I have really had it with the NO TOKENS rule in scheme.  Scm3c has:

input-port?		output-port?
open-input-file		open-output-file	open-io-file
call-with-input-file	call-with-output-file
close-input-port	close-output-port

open-input-pipe		open-output-pipe
close-pipe

If I were to fill out this chart with the obvious procedures I would
have 18 functions just for opening and closing files.  I have not
created these out of idleness; I actually use them and the Scheme set
is not sufficient for my work.  I want to add unbuffered versions as
well (open vs. fopen) which will result in a grand total of 36.  Oh, I
almost forgot, on MSDOS machines (one of the platforms that scm3c runs
on) there is a difference between binary and text files.  That will
bring it up to 72 PROCEDURES JUST FOR OPENING AND CLOSING FILES.

This situation is obviously untenable.  I am going to implement (OPEN
file mode).  My current idea is that it will be POSIX compatible if
mode is an integer and ANSI C compatible if mode is a string.  It will
return #f if the operation is not successful.  I can implement the
required functions in terms of OPEN and ERROR.

The RnRS committee seems to show little enthusiam for putting together
a comprehensive I/O system.  Why not let POSIX do it?