Re: [Gcl-devel] unhappy error handler

[Peter Wood]

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