[ansi-test-devel] COMPILE-FILE.2 & COMPILE-FILE.2A

[Tobias C. Rittweiler]

Sam Steingold <sds at gnu.org> writes:

> The aforementioned tests check that compile-file reports warnings and
> style-warnings generated by the code being compiled (as opposed to the
> compiler itself) as its secondary and tertiary values.
>
> http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm
> The secondary value, warnings-p, is false if no conditions of type
> error or warning were detected by the compiler, and true otherwise.
> The tertiary value, failure-p, is false if no conditions of type error
> or warning (other than style-warning) were detected by the compiler,
> and true otherwise.
>
> the tests assume that if the code being compile does something like
>
> (eval-when (:compile-toplevel)
>   (define-condition w (warning) nil))
>   (warn (make-condition 'w)))
>
> then the compiler must notice this and report this (second value being T).
>
> It seems to me that the spec requires the 2nd and 3rd values to
> reflect the signaling from within the compiler, not whatever is
> signaled by the code being compiled.
>
> do you agree with my interpretation of the spec?

Let's use the terminology as clarified in Issue COMPILER-DIAGNOSTICS:

Conditions from EVAL-WHEN processing and macroexpansions are
conditions signalled -within- the compiler, the others are conditions
signalled -by- the compiler itself.


Now, your argument is that the return values of COMPILE-FILE should only
indicate conditions signals -by- the compiler. Right?


To recollect the terminology used in the standard about what the return
values indicate:


  CLHS entry for COMPILE-FILE, and COMPILE, talk of 

      "conditions .... detected by the compiler" 

  the issue writeup says

      "compiler diagnostics were issued"

  3.2.5 Exceptional Situations in the Compiler says
      
      "Both compile and compile-file return three values, the second two
       indicating whether the source code being compiled contained
       errors and whether style warnings were issued."


I tend to disagree with your interpretation although I -can- see how you
read through the passages and came to that conclusion.

Perhaps I only disagree because your variant strikes me as the less
useful thing.

OTOH the following tidbit can be found in the issue write up

  "The second and third return values from COMPILE and COMPILE-FILE give
   some indication of whether there were serious problems encountered in
   compiling the file."

And while issues writeups are not formally part of the standard, they
provide insights into purpose, rationale, etc of decisions made during
standardization. 

I certainly think that errors durings eval-when processing, and macro
expansion -do- indicate serious problems during compilation, so they
should affect the return values of COMPILE-FILE.

  -T.