2006/6/30, Goffioul Michael <<a href="mailto:goffioul@imec.be">goffioul@imec.be</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>



<div>


<div dir="ltr" align="left"><font color="#0000ff" face="Arial" size="2"><span>What you propose does not change the fact that in 
normal cases, ECL will not execute the exit hooks in a normal state, but always through the 
atexit() handler. I would prefer a scheme where the top-level function is exited normally, such 
that the rest of the main() function can execute normally. And this should be the default ECL 
behavior.</span></font></div></div></div></blockquote><div><br>Actually what I had in mind is to have at least two handlers for an exit condition.<br><br>1) Default handler calls cl_shutdown() and then exit()<br><br>2) When the toplevel is entered, it binds another handler that quits the toplevel using THROW.
<br><br>Additionally, a routine called ecl_handler_bind() will be provided for registering C functions to handle conditions.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial" size="2"><span>This QUIT implementation is annoying when you embed ECL 
into a larger program, because if you send the QUIT command to the LISP engine, it's 
the all program that is crashing.</span></font></div></div></div></blockquote></div><br>Yes, I agree, but the meaning of QUIT is indeed very much application-dependent. There are applications out there that will not use the toplevel, but define its own. The THROW solution is there a hack, because we have to expose the value of the throw tag, etc, etc.
<br><br>One can provide two alternatives: either each one is forced to redefine QUIT (in your case this is a good temporary solution) or you provide a robust mechanism as the one defined before, where people can intercept the exit conditions -- and even ignore them compeletely!
<br clear="all"><br>Regards,<br><br>Juanjo<br><br>-- <br>Max-Planck-Institut für Quantenoptik<br>Hans-Kopfermann-Str. 1, Garching, D-85748, Germany<br>Phone: +49 89 32905 345   Fax: +49 89 32905 336<br><a href="http://www.mpq.mpg.de/Theorygroup/CIRAC/">
http://www.mpq.mpg.de/Theorygroup/CIRAC/</a>