[Gcl-devel] condition-proposal UPDATE

[Peter Wood]

Hi

Much to my surprise, ACL2 _does_ compile with a GCL incorporating the
changes I am trying for an ansi condition system.  Maxima,
unfortunately, does not.  The previous time I tried compiling ACL2 I
was using the saved_gcl image from a build with --enable-ansi, and the
ensuing package confusion broke the ACL2 build.

Anyway, ACL2 is working, if I specify --disable-ansi in the GCL I use
for it..  So this is what I have:

=== Summary =================================================

(1) All errors in the C code base specify the type of the error, along
with the error message.  All calls to FEerror have been replaced with
calls to Icall_error_handler.  Calls to FEwrong_arguments_etc have not
been replaced, but changed in o/error.c to also specify ansi types.

(2) A tree of conditions in clcs/condition-definitions.lisp which is
ANSI compliant.  I use simple-package-error, simple-stream-error,
simple-program-error, simple-control-error, simple-parse-error,
simple-reader-error and simple-storage-condition (all in CONDITIONS
package) to report errors of those types (minus the 'simple).  The
reason for this is that CL already has the convention of simple-error
and simple-type-error for errors which take a format string as their
first arg.

(3) The hash table in kcl-cond.lisp has been simplified. It now looks
like this (in list form):

(defparameter *internal-error-list*
  '((division-by-zero :operands)
    (type-error :datum :expected-type)
    (end-of-file :stream)
    (unbound-slot :instance)
    (print-not-readable :object)
    (arithmetic-error :operation :operands)
    (unbound-variable :name)
    (undefined-function :name)
    (cell-error :name)
    (package-error :package)
    (file-error :pathname)
    (simple-type-error :format-string :format-arguments)
    (simple-error :format-string :format-arguments)
    (stream-error :stream)
    (:simple-stream-error conditions::simple-stream-error)
    (:simple-package-error conditions::simple-package-error)
    (:simple-storage-condition conditions::simple-storage-condition)
    (:simple-program-error conditions::simple-program-error)
    (:simple-control-error conditions::simple-control-error)
    (:simple-parse-error conditions::simple-parse-error)
    (:simple-reader-error conditions::simple-reader-error)))

and it works.  The table is only there for the benefit of the c-code
which calls Icall_error_handler.  The user should never access
anything here directly.

There is no real support for print-not-readable, yet.

(3) WALKER SLOT-ACCESSOR-NAME ITERATE PCL and CONDITIONS packages get
built in o/package.d, conditional on --enable-ansi.  This is so
raw_gcl knows about these packages, otherwise (compile-file "foo"
:system-p t ...) produces files which reference non-existent
packages.  This is a possible first step to incorporating PCL and CLCS
into the main build.

(4) I have added support for an optional 'condition argument to
compute-restarts, find-restart, abort, continue, muffle-warning,
store-value, and use-value.  Also the accompanying required
:test-function slot in the restart struct.  By default, this is
initialized to a function which returns T for all conditions.

(5) I have reformatted clcs/*.lisp, so parens don't hang on a line by
themselves, downcased the text, and removed the (apparently) useless
clcs/test* files which look to me like working drafts for
condition-definitions.lisp.  Also, I removed most of the #+xyz etc
conditionals on the assumption that if these files are being
incorporated into GCL we can do without this extra line noise.

(6) GCL built with --disable-ansi has the new condition types, but
obviously uses SERROR.  This happens transparently, and didn't require
any extra code.  Everything appears fully functional.

=============================================================

I would like to continue working along these lines. (And take a look
at the 'lambda-closure 'lambda-block-closure non-ansi thing).

What do people think should happen to GCL?  Go ansi? Maintain CLTL1?  
Any comments welcome.

Regards,
Peter