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

Re: output stream API

This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 are here. Eventually, the entire history will be moved there, including any new messages.



Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

>> 6. It would be great if there were a mechanism specified for passing
>> additional arguments (options) between the levels. Learning from
>> other existing I/O libraries, it is a recurring problem that you
>> need to pass funny little hints (e.g. access permission flags) down
>> (and sometimes up) the protocol stack to do what you need to do. I
>> am not talking about arcane IOCTLs, but over simple things like
>> opening a file for writing with the right attributes to actually be
>> able to write to it (this is no joke, R5RS open-output-file does not
>> specify what happens if the file exists.)
>
> That's definitely true.  At the time of writing, I didn't have a good
> solution, so I stuck with using separate procedures for the common
> options.  (I really dislike keyword arguments for various reasons.)  I
> have a better idea now, and I'll try to do something about the issue
> with the next revision.

Having said that, note that I fully expect platform-specific options
to come up, as well as platform-specific methods for creating readers
and writers.  That's not inherently bad, given that the sets of
available options *are* platform-specific.  It would be nice to
standardize on those as well, but they don't fall in the purview of
this particular SRFI.

(The SML Basis actually has a fourth, OS-specific layer, with variants
for Unix and Windows.)

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla