Error Proposal #5 questions

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: 24 Mar 86 18:07 PST
    From: Daniels.pa at 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*)

I'll add some examples. This is supposed to use CONDITION as a "free" variable
and do output to *STANDARD-OUTPUT*. Eg,

 :REPORT (FORMAT T "~A" (FROB-AROUND-WITH CONDITION))

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

I've never seen any good reason to assign one's slots in any code I've written
in Zetalisp. I think we might want to add wording saying that it's an error to
assign their slots. Obviously(?), for debugging it may be necessary to sometimes do
that and implementations should be permitted to support such. But I'm content to
have such be not portable.

    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.

Well, the SIGNAL description says that the signal facility is invoked. I meant it
to be the case that SERIOUS-CONDITION had a default handler that non-proceeably
entered the debugger, so no, it couldn't happen. That would be most like Zetalisp.
Personally, I don't like what Zetalisp does. I think you should have to use ERROR
if you don't want to proceed and SIGNAL if you don't mind and the default handlers
shouldn't exist at all. This would clean up some things. But it might be very
incompatible with Zetalisp. Also, it's not something that I have any active 
experience with. I just have experience with the way Zetalisp does things, which is
very adequate and usable if slightly inelegant. I'm torn between personal desires
for purity and a desire to make sure we lean toward "field tested" techniques where
possible. But I'm willing to listen to arguments on the subject.

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

Yes, that's right. If a condition is passed, its report function is used. In 
principle, you can WARN things that are not based on WARNING, by the way. I
dunno if anyone would do that, but it's legal in my proposal. I saw no reason
to forbid it, so I didn't.)

    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?

I don't think these are really contradictory, though I'm content to clean up the
wording. The real intent is that every proceed function looks for proceed cases
by the same name. As such, you could provide a named proceed case and not have
yet written the corresponding proceed function. I guess I think that the thing 
to avoid is making proceed cases named things like CAR or STRING-SEARCH where the
name is obviously not the name of a proceed case. Do you have any strong feeling
about whether it would be best to disallow cases that don't correspond to actual
proceed functions? Certainly this is something that compilers might try to warn
about in any case.

    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?

I'm not sure what to make of this ungrammatical mess, but I'll give a shot at 
answering the question I think you're asking. DEFINE-PROCEED-FUNCTION is intended
to be actually implemented as the cdr of an &OPTIONAL var list, so I guess it would
be hard to keep supplied-p from working. And as you say, it would be handy in some
cases, so let's write it in.

    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?

Yes. The obvious reason is that proceed functions are functions. Functions
get their arguments evaluated, optionals filled in, etc. To go a bit deeper,
though, let me add that basically a named proceed function just does:

 (DEFUN myfun (CONDITION &OPTIONAL ...variables as in define-proceed-function...)
   (LET ((CASE (FIND-PROCEED-CASE 'myfun CONDITION)))
     (IF CASE (INVOKE-PROCEED-CASE CASE CONDITION ...varnames given in define-proceed-function...))))

The only difference is that it also sets up information about the default values of
:REPORT, etc. for that proceed case. So obviously, it doesn't find out the case
is missing until after the optionals are processed, etc.

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

As should be obvious from my answer to 7 above, proceed functions call 
INVOKE-PROCEED-CASE and not vice versa.

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

Fine idea. I hoped that if I put down a random set of things that it would 
sufficiently offend someone enough that they'd start telling me how to fix the
list. When I mentioned that we just needed a set of condition types, no one 
came racing up with a nice set. If you think of other obvious ones, let me know.

    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.

Well, the intent is that you should suggest a type and we should include it. 
However, we are going to get to a level of detail where people no longer agree.
At that point, I expect implementations to continue to make more-specific 
condition types where they feel it appropriate and then signal them. ie, if
we added nothing for PARSE-NAMESTRING, implementors should know that they should
at least define a FILE-ERROR (or some such) on their own and signal that instead.
Some will signal FILE-PARSE-ERROR, some will signal FILE-NAMESTRING-PARSE-ERROR,
etc. It may be the case, of course, that ERROR will be the best thing a portable
program can look for. Anyway, let's assume there's a FILE-ERROR. (It got left out
because I had originally mis-named STREAM-ERROR by that name but then forgot 
FILE-ERROR would still be valid/useful when I renamed what I had been calling
FILE-ERROR to STREAM-ERROR.)

    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.

I believe this is a very good idea. It's certainly something I'd intended to do
sometime. We should do it if possible, but we should not let the failure to do
it keep us from agreeing on this error proposal in short order since any sort
of standard in this area would be better than what we have now.

I think these were all excellent questions, by the way -- just the right level of
detail that I think we should now be addressing. I hope I've answered them coherently;
it's a bit past my bedtime. Let me know if something got garbled or if I've raised
new questions with my answers.