[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] condition system proposal

From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] condition system proposal
Date: Mon, 04 Nov 2002 13:50:55 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526

It seems that Peter is doing right things.  Great!

But I just wonder can we really bring conditions
in sync with ANSI CL standard using the way
GCL ansi image is build now with successive
addition PCS as CLCS (conditions).  If not
then we sooner or later have to recreate
build process from scratch.

Second point is serror.lsp and SERROR
package.  As far as I understand this
is old substitute for CL conditions.
Can we get rid of this package as soon
as ANSI conditions are in place?
On the other hand I know that now
Maxima relies on SERROR.

Peter Wood writes:

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

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
        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

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)

        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. ;-)


     Vadim V. Zhytnikov


reply via email to

[Prev in Thread] Current Thread [Next in Thread]