Hi On Thu, Mar 10, 2005 at 07:30:09AM -0500, Camm Maguire wrote: > Greetings! >
... > > 1) At the C level, your idea of macros passing the right keyword or > symbol and changing the hash table in clcs_kcl_cond.lisp > accordingly is right on. I think I can implement this without too > much pain, I still have your old patch as a starter. > > 2) You note the serror functionality in the thread, to which Vadim has > also separately referred, describing it as a pity to sacrifice for > conditions, though a necessary one. Are we free in ANSI to build > conditions on top of serror as you appear to imply, presumably by > making the condition type inherit the error type or some such? > What exactly is it about serror that is worth preserving? Perusal > of the comments in gcl_serror.lsp indicates that some considerable > thought was put into the efficiency and flexibility of the > implementation -- not sure how this compares with clcs yet. I really just meant that a lot of work and thought had gone into serror and it seemed a shame to chuck it out. On one hand, serror is small, neat and efficient, on the hand, the ANSI condition system is necessary, though, if we ever want to claim to be ansi. We also can not build a new system on top of Serror, since ansi requires us to use CLOS for the condition system, and serror is not at all integrated with CLOS, while CLCS is, to some extent. My plan (of which you have an old patch) was/is quite workable and I think made the condition system mostly compliant. If I remember correctly, all places in the c code which were calling FEerror were changed to call Icall_error_handler directly with a (cl) symbol which named the ansi condition which should be created by the error handler, and any other args needed to describe the condition When the non-ansi image was being built, serror was using the same symbol to make an serror-condition. The hash table in clcs (kcl_cond or whatever) was to have a key consisting of the symbol naming the ansi condition. In those cases where GCL needs to signal a non-ansi condition, I was using a keyword to name the condition. I don't know why the current hash table contains format strings. It seems a bizarre place to put them. What I remember most clearly about writing that stuff was that it is actually a good idea to have a pretty clear idea of what the ANSI cl condition system requires, ie the _details_, since it is easy to use a lot of time doing something reasonable which just turns out to be wrong by the spec! AAARGH. > 3) My plan is to effectively remove the recursive block except in > cases of storage-condition, and to make sure we throw this at the > right places. Whether or not this requires a separate handler or > code within the same handler would appear to be a somewhat > arbitrary choice, no? > Yes. Good luck. I hope the patch is useful. It's a bit old now. Regards, Peter _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
