[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: file options
Sebastian Egner <sebastian.egner@xxxxxxxxxxx> writes:
> 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:
> As you see, the options convey information that is being used to
> format the output sent to the file.
Sure---but exactly what corresponds to FILE-OPTIONS is explicit,
The stuff that corresponds to the "format" sits in the
transcoder---and that indeed does have a default.
> As a hypothetical example, think of a SRFI defining the following thing
> for distributed execution: [...]
> 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.
Sure, but this is a job for a serialization library---READ and WRITE
as in R5RS are not that library. (In fact, R5RS specifies at least
one object that *must not* have an external representation, namely the
EOF object.) So, it seems this should be addressed in a separate SRFI.
> 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.
Hm. I'll think about it.
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla