Mike Sperber wrote:
> 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?
>
> > 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.)

Both issues (external repr. and retrieving the file-options from a file) are related to
the same thing, so I discuss them together.

In the Mathematica programming language you can open a file for adding stuff
using the OpenAppend operation. This operation has a number of options,
with defaults, each of which can be overwritten using Mathematica rules. In
Mathematica, that is the mechanism to pass options---it works very well;
a lot to type, but I never made a mistake and the defaults work well.

The options of OpenAppend are described here:

        http://documents.wolfram.com/v4/RefGuide/OpenAppend.html

As you see, the options convey information that is being used to format
the output sent to the file. Other options would be more related to the operating
system, i.e. file permissions, but these are not part of Mathematica.

Now I have the feeling (it's not much more than that right now) that the day
may come where the options should be externalized and internalized again.
As a hypothetical example, think of a SRFI defining the following thing for
distributed execution:

        (WITH-REMOTE-PROCEDURE-CALL server thunk)

which connects via some RPC-based middleware thingy to /server/ and
then executes /thunk/. The idea is that all I/O commands, including opening
files, are executed on the server. This will be great if (and only if) the I/O API
can be used without knowing what it is, i.e. if the client and the server can
run different operating systems, Schemes systems etc. but still know enough
about each other to do meaningful things.

In practice this will only be possible if a number of things fit together:
1. The entire negotiation between language and OS can be represented
in a data structure.
2. The data structure can be sent losslessly through a WRITE/READ channel.
3. The default behavior makes sense in all cases that do not require special
treatment anyhow (e.g. if you need a pipe, you better have an OS that has them).
4. There is a way to reconstruct the negotiation later from the object itself,
i.e. you can get the options back from the file.

The last point might not really be essential, but I have seen great programs
to find out if a file descriptor in C is connected to file or a ptty because in one
case you might to do this, while in the other you might do that. Of course, this
information could be passed from the guy who made the file descriptor to
the guy who uses it on a side-channel, but in UNIX that is not what happens;
you poke around with fcntl/ioctls until you can guess it.

What I have sketched here is an extremely strong form of portability,
and I am not sure the world is ready for that. I am also not sure the plan
can really be executed. Also, I admit that it has no precedent in the civilized
world---you should be happy if the language gives you a reasonable way
of opening a file /locally/, like Ruby, Python, ... (missing something?)

> > 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.

So that's what DEFAULT-FILE-OPTIONS could be for.