[Shootout-list] NOT ACCEPTED: Program should use exception handling.

[skaller]

Felix exception test says:

"NOT ACCEPTED: Program should use exception handling."

Thanks for giving reason at least.

So now please apply it consistently and disqualify gcc.
Both gcc and Felix require the handler closure be visible,
its a procedure closure in Felix, or a jumpbuf in C.

As far as I can tell, Scheme also uses a related technique:
call/cc also requires an explicit closure (but I'm not
a Scheme programmer so I could be wrong).

Personally, I think there is a overzealous and prejudicial
interpretation of what 'exception handling' actually is.
The way it is done in Java and C++ not only isn't the
only way -- it is arguably the very worst possible technique.

Many programmers, including me, curse Ocaml libraries
that throw exceptions and regularly catch them locally
and  convert functions to return sum(union) types instead.
This is basically the old-fashioned functional technique
used in C of returning an error code (with better language
support).

Haskell can make this less painful syntactically
using a monad (but it is still passing the error
code explicitly).

Whether or not you agree with this argument isn't 
important. What matters is the definition of
'exception handling'. As far as I am concerned
any technique that yields the correct results for the
test should be allowed. You don't have to agree with that
either, but if you want to restrict the technique you just
can't use waffle words like 'exception handling' as 
a constraint and then arbitrarily disqualify one
program and not another. Well, you can, but it won't
give the Shootout a good name :)

Felix uses a nonlocal goto. (possibly wrapped in a closure)
The essence of exception handling is captured in
the non-local goto -- doing one drops the current
context in favour of the an 'up stack' context.

I'm slightly surprised Felix outperforms C on this test.
Felix does more work -- it actually does have to unwind
the stack, one frame at a time, searching for the handler
frame. Just like C++ does.

The fact is, the Felix technique subsumes type based
exception handling -- it is considerably more dynamic
and flexible, given that in C++ you can only throw
an object of a statically visible type. In Felix,
you can just put a closure in a statically visible
variable .. which is more powerful because that
closure can be changed dynamically.

In Felix I expect the performance goes down with the length 
of the throw, and there is also a cost *passing* the handler.

Why not make a second version of the test, in which
the throw is only done 1/1,000,000 of the time,
to see what the cost of *not* throwing a catchable
exception is? 

Another variant is to throw from a heavily recursive
routine, so the stack length from throw to catch is large.

[Ackermann's function comes to mind, but there's a problem
there measuring Felix .. Felix really DOES throw C++
exceptions inside functions: you need to understand
that functions in Felix work like C++, whereas
procedures are stackless so they can be micothreaded..
it's an uncomfortable balance and I can probably design
tests that demonstrate this]


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net