Simon Peyton-Jones <[EMAIL PROTECTED]> writes:
> I'm not prepared to add new functions to Haskell 98, but I think
> the clarification of (1) or (2) below would be useful. (2) is nice
> but it makes *all* file reading more expensive, perhaps significantly
> so (e.g. making a complete copy of the file).
Well, as noted (
> | [1] On Unix-like (POSIX?) systems, unlinking the file and
> | then opening the writable file would be sufficient. On
> | certain legacy OSes, the implementation would have to
> | read the rest of the file into memory before creating
> | a new file under the same name.
) the unlink shouldn't cost much, except in terms of disk space, and I'm
mostly using Unix systems anyway, so I'd vastly prefer that. Surely
the file wouldn't need to be loaded into memory on any but the most
atrocious OSes? A rename into some temporary file should be possible
at low cost.
There are of course problems with that approach:
What if you only have write access to the file, and not its
directory? And using a tmp directory might mean moving data
across file systems, instead of just renaming.
Could NT's (or others) multi-forked files be useful, I wonder?
I.e. rename the default fork (stream, whatever) in the file, redirect
subsequent reads, and write a new default fork?
> So I am personally inclined to go for (1) and require Haskell
> programmers to do the consequent file-name changing themselves.
What can I say? Yuk. This would probably mean that I'd have to do a
lot of explicit file copying, and probably more than really necessary,
just to be on the safe side. In other words, while option (2) might
have a cost on less developed systems, option (1) will carry at least
that cost on all systems.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
