[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?