>> > I very rarely have problems with this.
>> Very rarely having problems with something can't save it from being
>> a very bad practice.  Not explicitly closing your files is (in 99% of the
>> cases) just sloppy coding.
> If we're talking about programs which are expected to run for an arbitrary 
> amount of time (servers, the top-level etc.) then yes.

This logic is routinely used in C to simply never call `free' because they
only run for a short time.  That's a textbook example of "sloppy coding".

>> Kinda like letting a GC finalizer close  your windows: when the effect is
>> visible from outside the process it shouldn't be done in a finalizer.
> The term "visible" in this context is subjective.

I wouldn't call it "subjective", but it is indeed relative to a set of
assumptions about what is "visible" and what isn't.  My assumptions here are
generally that CPU-time and swap-space use are "invisible".  The CPU-time
part is mostly intrinsic in the fact that I write in a high-level language
on top of a multiuser OS and don't have any direct control over the actual
assembly code generated, nor over the scheduling decisions.  The swap-space
part is a basic assumption of a tracing GC.  They're not ideal assumptions,
but without them life is a lot more difficult.

In contrast "the content of my file when another NFS client tries to read it
20 seconds after I generated it (and got an ocamltop prompt back indicating
it'd been generated)" is something that I do consider as "externally
visible" because it doesn't make life much more difficult: just close the
file when you're done with it.  It's extremely rare that the point in the
code where a file can be closed is not trivial to find.


        Stefan