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