Tue, 05 Sep 2000 12:10:14 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> H98 doesn't really specify what happens in this situation.
> I think, there are two ways to solve that:
Similar problem is in the case of hClose on a semi-closed handle.
For example in GHC it means that whatever was not evaluated yet,
will be lost.
When one hCloses a semi-closed handle, he might mean one of two things:
- He is not interested in this file nor its contents any more.
- He wants to process what was read by hGetContents but have this file
physically closed, as if hGetContents was strict.
There is no perfect way to automatically distinguish between these
cases. When the handle hidden in the free variables of the contents
string is finally garbage collected, the RTS may be certain that the
first action was needed and the file may be forgotten, but when it's
still alive, we _probably_ should read the rest into memory and then
close it.
There is a chance that it was not garbage collected yet but it's dead,
and reading a whole 10 megs of file when the user losed its interest
after first bytes is unnecessary. So this is not a sufficient rule.
I don't see how to do this without extending the interface.
> In the case that solution (1) is chosen, I think, we should also
> have something like `strictReadFile' (and `hStrictGetContents')
> which reads the whole file before proceeding to the next IO action.
It's not enough too: it forces strict reading from the beginning,
where what could be really needed is to process almost the whole file
sequentially and finally ensure that anything more is read too.
It is sufficient - but perhaps not the nicest interface - to have
an operation on a semi-closed handle which ensures that everything
previously told to be read lazily is actually read now, which of course
causes closing the file afterwards. hClose would be left as is in GHC,
to be able to lose interest on the file without the danger of reading
the whole. It means that instead of readFile, hGetContents should be
used in cases this operation is needed.
Could hFlush be reused for this? :-) Probably no, it's a different
thing.
Alternatively, hClose could do that, but there should be a variant
of hClose that means losing interest.
Since it does not give best possible behavior in case of writeFile
after reading on Unix, perhaps it should be combined with your rule
(2).
> Otherwise, in situations like in the mentioned assignment, you have
> to resort to reading the file character by character, which seems
> very awkward.
Actually you could apply
foldr (\_ x -> x) (return ())
or even
foldr seq (return ())
to its lazy contents. But it seems too bad for an official method.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
