Invisible wrote:
> Actually, for reasons beyond my comprehension, if a Haskell program 
> halts abnormally, all files are closed, but not necessarily *flushed*. 

Because it's Haskell that flushes the buffers to the file, but it's the 
OS that closes the file. If you run it on (say) an Amiga, it won't close 
the files, either. Apparently Haskell isn't writing directly to the 
files, but to Haskell-managed buffers. Same thing happens in C with stdio.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:

> 
> The destructor will close the file when the GC collects the object, but 
> that might be several seconds later. And it might not run if you exit 
> the program before the GC runs, but that's true of C++ also. So it's not 
> quite as nicely deterministic, but it still happens eventually.
> 

C# has the same issue. You can sort of work around it with the using 
statement, which will call Dispose on an IDisposable object, which, in 
turn, closes the file.

-- 
~Mike

Post a reply to this message

Mike Raiford wrote:
> Darren New wrote:
> 
>>
>> The destructor will close the file when the GC collects the object, 
>> but that might be several seconds later. And it might not run if you 
>> exit the program before the GC runs, but that's true of C++ also. So 
>> it's not quite as nicely deterministic, but it still happens eventually.
>>
> 
> C# has the same issue. You can sort of work around it with the using 
> statement, which will call Dispose on an IDisposable object, which, in 
> turn, closes the file.

Yep. Of course, it's really not a problem in a system where the kernel 
participates in the GC, like Singularity does.

And, really, memory is a huge percentage of the resources you manage, so 
the small bit of "real" resources you have to handle manually is usually 
not much of a problem. Indeed, only once did I have code sufficiently 
convoluted and error-prone that I had a resource leak of this type in 
Tcl. And even then, it's because I wrote the code poorly and instead of 
(say) wrapping the allocation and use in a procedure call, I tried to 
handle it all inline.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Actually, for reasons beyond my comprehension, if a Haskell program 
>> halts abnormally, all files are closed, but not necessarily *flushed*. 
> 
> Because it's Haskell that flushes the buffers to the file, but it's the 
> OS that closes the file. If you run it on (say) an Amiga, it won't close 
> the files, either. Apparently Haskell isn't writing directly to the 
> files, but to Haskell-managed buffers. Same thing happens in C with stdio.

Yeah, but if the Haskell runtime has code to handle printing out a 
human-readable error message on an unhandled exception, why can't it 
also run some finalisers? This is pretty basic stuff!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Fri, 26 Sep 2008 16:30:35 +0200, Invisible <voi### [at] devnull> wrote:
>>    I think the only operator you can't overload is the dot operator.
>
> And .* (apparently).

:: and ?: cannot be overloaded either.


-- 
FE

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > Looks like it would only be useful for some pretty obscure situations...

> Really? They're useful all the time in C#. Like, every time you have a 
> callback function you register with the GUI, or every time in Java where 
> you'd have to create an anonymous inner class or something. Pointers to 
> members are the OO mechanism corresponding to closures.

> You have a window representing an object. You want to be notified 
> whenever the mouse moves over the window. How do you tell the window 
> manager that?

  Isn't this usually handled with callback interfaces (in OO languages)
rather than function pointers?

-- 
                                                          - Warp

Post a reply to this message

Fredrik Eriksson wrote:
> On Fri, 26 Sep 2008 16:30:35 +0200, Invisible <voi### [at] devnull> wrote:
>>>    I think the only operator you can't overload is the dot operator.
>>
>> And .* (apparently).
> 
> :: and ?: cannot be overloaded either.

That seems logical...

I bet you can't overload ";", can you? In Haskell, you can. >:-D

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

>   Isn't this usually handled with callback interfaces (in OO languages)
> rather than function pointers?

Speaking of which... apparently you can overload "()", thus creating an 
object that looks like a function... How far-out is that? o_O

I'm almost tempted to try just to see if I can implement curried 
functions with it in C++. You know, just to be totally perverse...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Unless I'm completely mistaken, this is not something you can achieve
> > in Java. (In Java you have to close files explicitly and catch all
> > possible exceptions which might otherwise bypass that closing.)

> The destructor will close the file when the GC collects the object, but 
> that might be several seconds later.

  I don't know how it is today, but at least in the past the amount of
file handles one single program could keep open at the same time was
ridiculously limited (IIRC to a few dozens or so). If the program tried
to open more than that, it would fail.

  If a program is constantly opening files, doing something to them, and
then closing them, a file handle leak (which would happen if it fails to
close them for some reason, eg. because of a bug or a suprising exception)
can cause the program to malfunction. And this might not be caught on
testing, if the testing fails to stress the program in the same way as
it happens in actual usage...

  OTOH, I could imagine that if Java detects that a file cannot be opened
because of too many file handles being open, it could automatically try
to run the GC and then try again.

  OTOH, file handles are just *one* possible resource which can leak.
Java can't be prepared for all of them.

> And it might not run if you exit 
> the program before the GC runs, but that's true of C++ also.

  It's true of C++ only if your stream has been allocated dynamically
(directly or indirectly). If it's stack-allocated then there's no way
its destructor won't be called.

  (Ok, there is a way: If you call abort() the program is immediately
terminated without any stack unwinding, in which case no destructors
are called at all. However, abort() is such a harsh way of terminating
the program that it shouldn't happen in normal code.
  Incidentally a failed assert() calls abort(), which is the reason why
assert() should only be used to catch programming errors, not to exit
the program normally.)

-- 
                                                          - Warp

Post a reply to this message

On Fri, 26 Sep 2008 19:44:56 +0200, Orchid XP v8 <voi### [at] devnull> wrote:
>
> I bet you can't overload ";", can you?

';' is not an operator. It is a statement terminator. It would make no  
sense for a C++ program to redefine the meaning of ';'.


> In Haskell, you can. >:-D

Can you overload/redefine '->' in Haskell? What about '()'?



-- 
FE

Post a reply to this message