Re: file options

[Sebastian Egner <sebastian.egner@xxxxxxxxxxx>]

Mike Sperber wrote: 
> Sebastian Egner <sebastian.egner@xxxxxxxxxxx> 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.