issue COMPILER-DIAGNOSTICS, version 2

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

The problem description seems well-stated.

I wonder: is it really true that COMPILE-FILE's return value is not
well-defined and that it is not covered in Cleanup issue
ARGUMENTS-UNDERSPECIFIED? That's a small point, of course.

    Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:

    (1) Clarify that COMPILE-FILE is allowed to print messages indicating the
	normal progress of the compilation.

I would prefer that we started to control this more tightly. On some systems,
the compiler types out info about each function as it is compiled. On others,
it tells only that it is compiling the file. I would like a way to control
this behavior. Even the :VERBOSE option to LOAD has the problem that no some
systems it makes the function either print out information like  ``Loading...''
while on other systems it prints out information about each function. As such,
some systems think typing out `just' ``Loading ...'' is not verbose and others
think it is verbose. I don't want to see the same fate befall COMPILE-FILE,
yet I think it's important to think about. I would prefer something like
 :VERBOSE = T, :BRIEF, NIL (or :DETAILED, T, NIL -- depending on what you
			       think T should mean)
or maybe COMPILE-FILE should have a PRINT option.

This is a major hassle for Macsyma, by the way, which autoloads files in the
middle of running user applications and needs to be able to offer a similar
level of typeout independent of the host environment.

    (2) Clarify that both ERROR and WARNING conditions may be signalled within
	COMPILE or COMPILE-FILE.  Except for arbitrary errors which may occur
	due to compile-time processing of (EVAL-WHEN (COMPILE) ...) forms or
	macro expansion, ERRORs and WARNINGs may be signalled by the compiler
	only in situations which are clearly documented in the standard.  An
	implementation may signal additional ERRORs and WARNINGs only in
	conjunction with processing of nonstandard special forms supported as
	an extension to Common Lisp by that implementation.  All other
	implementation-specific programming style diagnostics issued by
	the compiler should be signalled as conditions of type NOTICE.

I think this goes at things from the wrong angle. I would prefer to see any
kinds of conditions be permitted to be signalled, but have the compiler required
to handle unhandled errors by turning them to warnings and aborting some
part of the compilation.

I think the restriction about what kinds of errors might be signalled is
very arbitrary and I doubt anyone will buy into it. As long as COMPILE-FILE
will trap the errors that the user handler (mentioned below) doesn't, the
user program is not going to break. If you say that other errors cannot be
signalled, you are saying that you have studied the language so well that
you believe there is no possible way for there to be a fatal error other
than those the CL committee has thought of. I just plain don't believe we're
that thorough and/or gifted with foresight. We must leave what the compiler
detects as open-ended, so I think the only answer is to expect that 
COMPILE-FILE will, in some cases, trap the errors we don't expect, and so
will tell us that the compilation has failed.

You'd have to be a lot more detailed about this NOTICE condition, where it
lives in the type hierarchy, whether there's a function that signals it,
whether it has any slots, what default handlers will exist for it, etc. to
make it believable, I think. I don't really recommend this.

    (3) Add a :HANDLER keyword argument to COMPILE-FILE, which is a condition
	handler function which is to be used during compilation.  If NIL or
	not supplied, COMPILE-FILE is allowed to establish its own
	implementation-specific condition handler, which may or may not cause
	the debugger to be entered when errors occur.  It is permissible for
	the default error handler to attempt to recover from the error and
	continue compiling the file.

This is an ok idea. But COMPILE-FILE should establish its handlers
unconditionally in case the user-supplied handler declines. Also, you probably
want to define that the ABORT restart will be handled and abort the smallest
feasible part of the compilation.

I see no reason to permit the compiler to enter the debugger at all. If
we need that, we should offer a keyword option. Systems can provide
other ways of entering the file compiler than COMPILE-FILE if they need
to offer such a capability.  COMPILE-FILE is a portable interface and
should behave as portably as possible.  To me, that means it should
always be required to enter the debugger on unhandled errors or always
forbidden. I prefer the latter.

    (4) Specify that COMPILE-FILE returns the pathname for the output file if
	it was able to successfully compile the input file.  However, if
	ERRORs occur and the compiler is able to recover and return normally,
	it should return NIL to indicate unsuccessful completion.

In some cases, the implementors may want to create a file even if it's bad.
As such, I think you should say it returns the pathname of a file if one was
created, and it always returns a second value saying whether the file is
believed `ok' (ie, no fatal errors seen).

    (5) Clarify that COMPILE does not establish a condition handler.  Instead,
	it uses whatever condition handler has been established in the environment
	from which it is called.

This sounds ok.

    Rationale:

I had to go back and re-write all my replies to this because I didn't realize
your rationales were point by point. I assumed all five of these points factored
over all five of the points above. Say something to indicate that you're doing
piecewise rationalization.

    (1) This reflects current practice.

Compilers vary quite a lot and it's quite irritating. See above.

    ...
    Current Practice:

Symbolics Genera usually tries to keep compiling when it encounters errors.
Symbolics Cloe ...

Regarding the other problem I mentioned above about progress/verbosity,
Symbolics Genera does not type out the name of each function as it is being
compiled; Symbolics Cloe (Runtime) does type out the name of each function
as it is being compiled.

    ...
    Cost to users:

    This is a compatible extension...

Make it clearer that although it's compatible, user code (which is probably
used to the randomized behavior now) would almost certainly need to change
in subtle ways. Usually such changes would be simplifications, but unlike
some functions which aren't well-defined portably it's hard to argue that
no one uses COMPILE or COMPILE-FILE in spite of disparate behavior, so we
have to acknowledge that this is, in practice, gonna break `portable' code.

    ...
    Benefits:

    Users are given a way to detect and handle compilation errors.

Say something here about uniformity/portability.

    Discussion:

    Pierson has suggested removing item (1) of the proposal and instead
    requiring the compiler not to print out any random informational
    messages.  We could define another kind of non-serious condition
    (INFO?) to take care of trivia like file names and progress messages.
    What do you implementors think about this?

I would prefer to see the interfaces to LOAD made more specific about what
kinds of options each of the keywords are supposed to control, and then as
symmetric as possible a set of options provided for COMPILE/COMPILE-FILE.

    The warnings and errors which can potentially be signalled during the
    processing of standard special forms and macros need to be spelled out
    in detail.

I strongly disagree. The -only- kinds of errors we should spell out are
the ones which we want to encourage people to handle portably. The
intricacies of how special forms, etc. are handled in each system means
there's unlikely to be any portable kind of fix you can make. Put another
way (suggested to me by Moon), do we want to encourage a `portable programming
style' which calls COMPILE-FILE with a handler for some UNSEEN-GO-TAG  
condition that somehow magically tries to correct it or do we want to just
say it signals a SYNTAX-ERROR and that the person should edit his code to
not reference non-existent go tags. It seems clear to me that the latter
is true.

We have very limited resources for spelling out condition meanings and those
resources should be directed toward things like common pathname errors
(no such directory, link to non-existent file, etc.) which we can reasonably
expect to feel good about handling in portable code.