freenode/#clasp - IRC Chatlog
Search
2:32:52
karlosz
and also it seemingly can't even reconstruct '(b (a . c)) from a cst with raw (a . c)
2:36:39
karlosz
nope, well scymtym added the test at the same time as the fix that was supposed to make the test work
2:38:06
karlosz
anyway i was going to try to make reconstruct faster since a lot of time is spent there
13:23:04
Bike
you're not supposed to throw exceptions out of C++ destructors because destructors are called while unwinding the stack in the course of exception handling, and if an exception is thrown while another exception is in flight, C++ terminates the entire program because it is a stupid language
13:23:48
Bike
"Because you see, what else could C++ do? There's an ambiguity: which exception out of the two do you want caught now? [...] That's right, terminate(). Solomon-style conflict resolution carried to the end."
13:25:16
Bike
in lisp the roughly equivalent situation would be signaling an error from a handler-bind handler (not handler-case)
13:25:57
Bike
because, and this is perhaps a bit subtle, in lisp we can handle exceptions before unwinding
13:26:38
Bike
so e.g. the second condition can be restarted in such a way that it goes back to the process of signaling the first condition, which ends up in the debugger. a bit convoluted, but no problem
13:27:15
Bike
actually i suppose the better analogy would be signaling an error from an unwind-protect cleanup
13:28:08
Bike
but the solution is the same - higher handlers can handle or restart the new condition, and in the latter case we just go back to the original unwinding process
13:28:51
Bike
in order to do this properly in clasp, every unwind protect catches every C++ exception, so that the cleanup can signal anew without getting recursive
13:29:37
Bike
bla bla bla explanations. i can explain C++ exception stuff more if anyone cares. i try not to be judgmental usually but this is a part of C++ i hate a lot