Sebastian Egner <xxxxxx@philips.com> writes:

>> - The procedures for opening files for output now accept a
>>   file-options argument.
>
> Sorry to keep bothing you with that, but I noticed two potential problems
> with the
> way this was solved in the SRFI:
>
> 1. File options do not have to have an external representation.

Right.  Why do they need one?

> 2. It is a little tedious to check, but are you sure the file-options are
> always passed around with the constructors?

Yes.

> Can I retrieve the file-options used for opening a particular
> reader/writer/... from the reader/writer/... object?

No, the file options are specific to files.  Can you argue why this
would be important?  (For example, C API doesn't have this ability
either, as far as I can tell.)

> My point is that it would be a great benefit portability if Scheme
> systems could at least *handle* the file options of any other Scheme
> systems. This idea is fragile in this sense that it can be broken at
> any time (e.g. procedures as options), but this SRFI might be the
> place to lay down the infrastructure for supporting it.

But the infrastructure is there---you can just add more flags to
FILE-OPTIONS, and the specification doesn't say that it's an error to
extend Its syntax.  (In fact, the reference implementation just
ignores what it doesn't know about.)  You could also add tagged fields
to it straightforwardly, even if it would mean some more work in the
reference implementation.

> Apart from that I noticed that the /file-options/ argument is
> mandatory. Is that really the intention? Shouldn't it be optional,
> with the obligation for the implementation to provide a reasonable
> default behavior?

The problem is that there's no obvious reasonable default, evidenced
by the fact that different Scheme implementations use different
defaults for OPEN-OUTPUT-FILE.

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