ERRSET

[Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>]

    >>>It might be a good idea for you to document exactly what this ERRSET
    >>>function is supposed to do and what its syntax is. 

    >>Yeah.  So far as I'm concerned, all it need do is something like this:
   
    >>(ERRSET <FORM>) where it evaluates <FORM> and returns it result in
    >>a list.  If any error occurs while evaluating <FORM>, then ERRSET
    >>returns NIL. 
    >>Most implementations have an optional second argument which controls the
    >>printing of error messages.  I think the default is to print them.
    >>Is this sufficient?

    >yes, but lets deviate from CL practice and spell the function reasonably.
    >errorp would work if it returned multiple values, the first being T
    >if an error happened, the second being the value of the expression
    >if no error.  If error, the value of the expression would be
    >meaningless so return NIL or a string of what was printed to
    >*error-output* during the evaluation.

Hummm...  Isn't this sort of thing being dealt with by the CL error-
handling proposal?  In it, there is a form IGNORE-ERRORS &body forms
that returns the value(s) returned by the last form in 'forms' if
no error (condition of type error) occurs; and nil otherwise.  The 
error message is not printed.

Is this what's needed or would something different be better?  I'm
thinking that the following things might need to change:
  .  The error message is not printed.
  .  There is no way to distinguish between an error and the last
     form returning a single value of nil.
  .  There is no indication of which error occurred.
The last two points could be handled by having IGNORE-ERRORS return
an extra first value before the ones returned by the last body form.
This value could be the condition signalled or else nil if no error.
(Note that conditions (and hence errors) are data objects in their
own right -- they're better things than message text for programs to
handle.)

Of course, the proposed error system contains more general forms that
could be used to construct whatever's needed, but, given that the
proposal contains a simple form (IGNORE-ERRORS) for the simple case,
there's no reason not to make it the right simple form.

-- Jeff