Re: [Gcl-devel] condition system proposal

[Peter Wood]

Hi

Thanks for your reply, Camm.  I was too wordy in my proposal, partly
because I was (partly) thinking aloud.  I am going ahead (in my
private sandbox) with a simplified version, after discovering that the
proposed macros are just obfuscating/confusing things.  Even if it
proves unworkable, at least I will ahve had a good tour through the
source code! ;-) I think the only way to discover the implications wrt
Maxima/ACL2 is (for me) to try it.

On Fri, Nov 01, 2002 at 12:03:20AM -0500, Camm Maguire wrote:
> Greetings, Peter, and thanks as always for your thorough ideas and
> work!
> 
> 1) I agree the error system is in a mess.  o/error.c, lsp/serror.lsp
>    and clcs/kcl-cond.lisp clcs/conditions.lisp all seem to have been
>    added at separate times.
> 
> 2) We need to find a way to smoothly transition to whatever new
>    structure we decide upon without breaking anything in maxima or
>    acl2.  GCL now compiles both of these on all 11 Debian
>    architectures plus a few other machines, and I'd like to keep it
>    this way at all times if possible.

I absolutely accept and understand this requirement.

> 
> 3) Many of Paul's tests have already revolved around this issue, and
>    many of my patches thus far have likewise addressed error
>    conditions.  If you look through the CVS log on kcl-cond.lisp,
>    error.c, and package.d (for example), you can see what's been done
>    so far.  In all of this I've attempted to take the minimal steps
>    necessary to fix the test without spoiling existing function
>    interfaces possibly in use by other code.  This has not always been
>    possible, but has in general been achievable as far as I can tell.
>    While this approach unfortunately makes for poor overall design, it
>    does allow us to focus on getting correct behavior quickly without
>    breaking existing functionality, and hopefully leaving us in a
>    position to redesign certain items once we've consolidated a bit.
> 

I agree that this approach is best, for now.  I realise that what I
want to do goes a bit deeper, and that there is a not inconsiderable
risk that the required backward compatibility gets broken.  I would,
however, like to note that there _also_ lies a danger in fixing code
to (just) pass tests, since it can tend to muddy the waters.

> 4) The error messages I've put in recently in particular need work.
>    I've tried to label such places with a FIXME comment in the code.
> 
> 5) This having been said, I don't think your proposal is necessarily
>    too radical for the above goals.  In fact, its quite similar to
>    what we've been doing in general, i.e. replacing all instances of
>    FEerror with something more specific.  So in general I like this
>    proposal very much.  Here are some thoughts which we might need to
>    discuss:  
> 
>       a) Do we need 'internal' error subtypes in any/all cases?
>       can't we throw the main type where allowed by the spec,
>       e.g. package-error? 

No we don't need 'internal' types, except where we want to change the
condition type itself.  If we want to add slots/accessors to an
ansi-standard condition we can only do so in our own 'internal' types
which should inherit from the standard type.  So far, the only place I
see where this might actually be necessary is in 'storage-condition.

> 
>       b) we need to make sure the interface allows us to specify
>       that the error is correctable.  See the 'specific-error' and
>       'specific-correctable-error' hacks in error.c

Why not just call Icall_error_handler/Icall_continue_error_handler
directly from where the error arises?  This is what I am trying at the
moment.  It does everything we need.

> 
>       c) A lot of existing lisp code calls (error "foo" ...).  So
>       does this mean we have to name a function with a fuller syntax
>       like (foo :internal-bar-error :correctable "asdasda" ...)(
>       something other than 'error'?  I've made this assumption thus
>       far.  

No.  (error "foo") in ansi means signal an error of type simple-error
with the format control "foo". 'error can be called with other
(appropriate) args, as well. 

>(error "foo ~a" "bar")

foo bar
<break loop, etc>

But _not_ keywords, AFAIK.

> 
>       d) Until we standardize on the ansi image (at least), whatever
>       we do has to work with the traditional image as well.  clcs
>       overwrites the function 'error' defined in error.c for the
>       traditional image.  

My suggestion works with the traditional image (as far as I tested ==
not very far) although it is necessary to define new (ansi)
conditions.

> 
>       e) while we're at it, we should also standardize where a given
>       error condition defines what data it takes.  There appears to
>       be code to this effect both in conditions.lisp and
>       kcl-cond.lisp.  Will every error of the same type have the
>       same error string?  I kind of like a dual solution like "Type
>       error: ~S is not of type ~S: <specific instance message if
>       available>".  Each instance could then pass clarifying
>       information -- see the previous error messages that were in
>       package.d before I truncated them to conform with the existing
>       package-error expectations.

To a certain extent this is defined for us by ansi.  The hash table in
kcl-cond is awful, and the old idea of hashing on both the name and
format string is ... bizarre.  However the new way doesn't work
either, since there are lots of different error strings for the name
:error, and the hash lookup is obviously only finding one entry called
:error !!  We don't need the format string info in the hash table if
each (C) function that needs to signal an error provides its own error
format string.  That's one reason why I want to report all errors in
the C code with Icall_error_handler (or Icall_continue_error_handler,
although I'm about half way through and I don't see anything that
signals a correctable error yet).  My proposal doesn't require the
slightest change in anybody's lisp code unless it is actually non-ansi
ie, relies on (traditional) GCL-specific error types.

> 
>       f) once we agree on a system (and I'd like to hear Paul's and
>       hopefully Vadim's comments here), perhaps what we would then
>       do is to decide that no one commits any further error fixes
>       while you work on your implementation.  Once you've verified
>       that all maxima and acl2 tests still pass, we can check it in
>       en masse to CVS.  With the current state of gcl, quite a few
>       people appear to be using CVS, so I'd really like to not break
>       it if possible.
> 

Again, I understand and accept this unequivocably.  I will under no
circumstances ever make any change big or small which I believe has
the remotest change of breaking CVS.  And BTW I consider myself still
bound by your request to confirm changes with the list before
committing them, so you don't need to worry on this account!

Perhaps I am jumping the gun in wanting to make deeper changes, but it
is going to be neccessary at some point, if we want to advertise ansi
compliance.  If we go out saying we are ansi without having a _solid_
claim to it, we will be ripped to shreds by the wild beasts out
there. ;-)

Regards,
Peter