Warp wrote:

>   I think that paper is a joke.

I really, *really* hope you're right about that...

Especially the use of multicoloured identifiers, and the use of dingbats 
as names!

-- 
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?

Only in languages that don't support pointers to member functions. In 
languages with closures or pointers to member functions, no. Just like 
in a language without pointers at all, the way you do callbacks is to 
redefine the function at link-time and then do a big switch statement.

C#, for example, has the "observer" design pattern built into the 
language as "delegates" or "events", accepting multiple pointers to 
member functions and letting the owner "invoke" all the methods pointed to.

Ruby and Smalltalk and all those pass around "blocks" for this 
functionality. Python passes around lambdas. LISP passes around 
closures. They're all essentially the same sort of thing, with ever so 
slightly different implementations, but all basically "a block of code 
with a pointer to an object's context".

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

Post a reply to this message

Orchid XP v8 wrote:
> 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!

Yep, true. I didn't realize you meant "exited cleanly due to an 
unhandled exception." I thought you meant "crashed out due to a signal, 
or running out of memory, or some such."

I suppose you could theoretically do a final GC and finalize before you 
exited (but perhaps before you printed the exception stack?), but I 
think at that point you're already pretty screwed. :-)

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

Post a reply to this message

Warp wrote:
>   I don't know how it is today, 

Usually a thousand or so, where such things are actually limited by 
something other than the amount of memory available.

>   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...

Yep. That's exactly what was happening to me in my Tcl code. When I 
could get the socket connection but it failed before it finished 
flushing the first buffer, I failed to close the socket. After a couple 
weeks of running, the program would bomb out with a file handle leak. 
That was very annoying to debug. I probably should have just tossed that 
whole function and started over.

>   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.

It could. That's what I like to recommend, but oddly few language 
designers listen to me. >8)

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

Well, it knows when something fails due to a lack of resources. It's 
even not unreasonable that (for example) opening a file could fail from 
lack of memory to put the stdio buffer in, or something, in which case a 
GC and a retry could correct it.

>> 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.

Yeah. And a sufficiently smart compiler for Java or whatever could do 
escape analysis, see that the stream isn't used outside the function, 
and stack allocate it and explicitly clean it up afterwards. Not that 
compilers quite do that yet.

>   (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.

That's what I was talking about, yes. I thought Andrew was referring to 
exiting Haskell with a core dump, basically, rather than simply an 
exception caught at the top level.

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

Post a reply to this message

>> 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!
> 
> Yep, true. I didn't realize you meant "exited cleanly due to an 
> unhandled exception." I thought you meant "crashed out due to a signal, 
> or running out of memory, or some such."
> 
> I suppose you could theoretically do a final GC and finalize before you 
> exited (but perhaps before you printed the exception stack?), but I 
> think at that point you're already pretty screwed. :-)

Basically, all you have to do is write a Haskell program that calls the 
"error" function somewhere, and your program will exit without closing 
anything behind it. Unless *you* remembered to take steps to prevent that.

That seems... a little unsafe to me.

Still, at least the code to do it isn't that hard.

   bracket
     (openFile "Foo.txt" ReadMode)
     (hClose)
     (\file_handle -> ...do stuff...)

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

Post a reply to this message

Orchid XP v8 wrote:
> Warp wrote:
> 
>>   I think that paper is a joke.
> 
> I really, *really* hope you're right about that...

""
Because this project relies of the ability
to fool the brain into accepting a projected image as 3D and because we 
don't take delivery of the 3D
projection device until next spring, this project is usually referred to 
as "Project April Fool."
""

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Isn't this usually handled with callback interfaces (in OO languages)
> > rather than function pointers?

> Only in languages that don't support pointers to member functions.

  C++ supports pointers to member functions, yet using callback interfaces
is a rather common idiom.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:

> ""
> Because this project relies of the ability
> to fool the brain into accepting a projected image as 3D and because we 
> don't take delivery of the 3D
> projection device until next spring, this project is usually referred to 
> as "Project April Fool."
> ""

Oh thank *God*!

Damn, he writes so convincingly...

[...says the guy who mistakenly took HGTTG seriously! o_O ]

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

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>   Isn't this usually handled with callback interfaces (in OO languages)
>>> rather than function pointers?
> 
>> Only in languages that don't support pointers to member functions.
> 
>   C++ supports pointers to member functions, yet using callback interfaces
> is a rather common idiom.

How do you declare a pointer to a member function, then?  I thought you 
had to keep a pointer to the object and then somehow invoke the proper 
member function, but I don't know the syntax for that latter part?

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

Post a reply to this message

Invisible wrote:
> (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I
> am *so* not trying that out!)

You can overload the comma operator!

boost::assign does some nasty stuff with it, to let you add stuff to STL
containers like this:

std::vector<int> mylist;
mylist += 1,2,3,4; // uses overloaded += and , operators

Post a reply to this message