Error Proposal #5 questions

[Daniels.pa@Xerox.COM]

1. I'm not sure what the second form of :report is supposed to look
like. Could I have an example of a use of it? (This is the case where
the report function goes to *standard-output*)

2. In previous versions, condition objects were immutable, i.e., all
slots were read-only. Is this still true?

3. If the condition signalled is of type SERIOUS-CONDITION, do you
always end up in the debugger if it isn't handled? The description of
SIGNAL implied that this may not be true.

4. In WARN, what is the "text of the warning" if a condition was passed
instead of a format string? (I assume that the way warnings are printed
is something like (FORMAT *ERROR-OUTPUT* "Warning: ~A." condition))

5. The definition of PROCEED-CASE states that a non-NIL name must
correspond to a defined proceed-function. This does not seem to be the
case, since INVOKE-PROCEED-CASE gives a way to get to that case. Which
is it?

6. The variable is DEFINE-PROCEED-FUNCTION differ from normal &OPTIONAL
parameters in that they to not allow a supplied-p parameter. Whay not go
ahead and make them the same as &OPTIONAL?

7. "If a named proceed function is invoked in a context in which there
is no active proceed case by that name, the proceed function simply
returns NIL." Does it still go ahead and collect parameters, or does the
test happen before any initial-value forms are evaluated?

8. If you hand INVOKE-PROCEED-CASE a name, does it simply unwind back to
the appropriate PROCEED-CASE, or does it call the proceed function? (The
answer is obvious if PROCEED-CASE names don't have to correspond to
proceed functions).

9. Since you've already define ILLEGAL-THROW and ILLEGAL-GO, it seems
like you should also have ILLEGAL-RETURN.

10. The list of standard condition types is incomplete. For example,
PARSE-NAMESTRING "signals an error if the hosts don't match." I couldn't
find an apporpriate condition to signal. It certainly isn't a
STREAM-ERROR, while simply using ERROR is distasteful -- it defeats the
purpose of having the type hierarchy.

This may be beyond the scope of the Error Proposal per se, but I believe
that there should be a well-defined condition for every place in CLtL
that indicates that an error is signalled. Of course, I don't mean that
we define a different condition type for each of these.

		-- Andy. --