COMPILE-FILE tertiary value, failure-p
in [Lisp]
|
From: sds on 30 Jul 2010 09:53 http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm 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 name suggests that if compilation signals non-style warnings, then the compilation has failed. is this indeed the intended meaning of the spec? E.g., compile-file of ==================== (eval-when (:compile-toplevel) (warn "foo")) ==================== will return failure-p=T because it will signal the "foo" warning, even though a perfectly valid FASL file will have been created. How should 3rd party build systems (asdf, defsystem et al) decide on the success and failure of compilation? - primary value (output-truename): if it has been created, then compilation succeeded - tertiary value (failure-p): if errors or non-style warnings were signaled, then compilation failed. Sam.
From: Pascal J. Bourguignon on 30 Jul 2010 10:33 sds <sam.steingold(a)gmail.com> writes: > http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm > > 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 name suggests that if compilation signals non-style warnings, > then the compilation has failed. > is this indeed the intended meaning of the spec? > E.g., compile-file of > ==================== > (eval-when (:compile-toplevel) (warn "foo")) > ==================== > will return failure-p=T because it will signal the "foo" warning, > even though a perfectly valid FASL file will have been created. > > How should 3rd party build systems (asdf, defsystem et al) > decide on the success and failure of compilation? > - primary value (output-truename): if it has been created, then > compilation succeeded > - tertiary value (failure-p): if errors or non-style warnings were > signaled, then compilation failed. I would say that it depends on the quality the third party build systems want to ensure. If you're happy with code that produce a fasl file, then just test the presence of it. If you want a bug free 100% guaranteed executable, then try to avoid spurrious warnings. As a user, I tend to be more confident in programs that compile without warnings than with programs for which the compiler must generate a lot of warnings. If the program compiles without a foo, then there should be no (warn "foo") it is source. If there's a need for a (warn "foo") in the source, then it definitely means the programmer is not sure that his program can be compiled without a foo. Therefore we can say the quality of this program is lower than a similar program of which the programmer is sure no foo may happen. (Of course, you have to trust the opinion of the programmers, but at least for a given same programmer, warningless is better than warningful). -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Pascal Costanza on 30 Jul 2010 11:08 On 30/07/2010 15:53, sds wrote: > http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm > > 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 name suggests that if compilation signals non-style warnings, > then the compilation has failed. > is this indeed the intended meaning of the spec? Yes, I think so. Section 3.2.5 of the spec says that "warnings might be signaled in situations where the compiler can determine that the consequences are undefined or that a run-time error will be signaled." Essentially, a warning is supposed to indicate that, although you can execute the code, it will most likely trigger a problem when doing so. > How should 3rd party build systems (asdf, defsystem et al) > decide on the success and failure of compilation? > - primary value (output-truename): if it has been created, then > compilation succeeded > - tertiary value (failure-p): if errors or non-style warnings were > signaled, then compilation failed. Preferably both should be possible. The first option may be good during development, while the second option is probably better for delivered code. There should be a reasonable default, plus a way to toggle between the two options. I'm not sure if it should ever fail on style warnings, but maybe that could be a possible third option. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: sds on 30 Jul 2010 12:05 On Jul 30, 11:08 am, Pascal Costanza <p...(a)p-cos.net> wrote: > On 30/07/2010 15:53, sds wrote: > > >http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm > > > 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 name suggests that if compilation signals non-style warnings, > > then the compilation has failed. > > is this indeed the intended meaning of the spec? > > Yes, I think so. Section 3.2.5 of the spec says that "warnings might be > signaled in situations where the compiler can determine that the > consequences are undefined or that a run-time error will be signaled." the sentence you are quoting starts with "In addition to situations for which the standard specifies that conditions of type warning must or might be signaled" i.e., _any_ warning may be signaled by the compiler. e.g., gcc warns "global register variables do not work as you might expect" (or something like that). is this a good reason to abort a build? > Essentially, a warning is supposed to indicate that, although you can > execute the code, it will most likely trigger a problem when doing so. "most likely"? how about "probably"? "possibly"? now about "might produce substandard results"? are you saying that any warning which should not terminate a build should be a style warning? what's the semantic (as opposed to behavioral) difference between a warning and a continuable error then? Sam.
From: Pascal Costanza on 30 Jul 2010 12:51 On 30/07/2010 18:05, sds wrote: > On Jul 30, 11:08 am, Pascal Costanza<p...(a)p-cos.net> wrote: >> On 30/07/2010 15:53, sds wrote: >> >>> http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm >> >>> 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 name suggests that if compilation signals non-style warnings, >>> then the compilation has failed. >>> is this indeed the intended meaning of the spec? >> >> Yes, I think so. Section 3.2.5 of the spec says that "warnings might be >> signaled in situations where the compiler can determine that the >> consequences are undefined or that a run-time error will be signaled." > > the sentence you are quoting starts with > "In addition to situations for which the standard specifies that > conditions > of type warning must or might be signaled" > i.e., _any_ warning may be signaled by the compiler. > e.g., gcc warns "global register variables do not work as you might > expect" > (or something like that). is this a good reason to abort a build? The spec doesn't say anything about C/C++ and its compilers anyway. Why do you expect the meaning of concepts such as "warnings" to be the same across different languages? Maybe I misunderstand you here... >> Essentially, a warning is supposed to indicate that, although you can >> execute the code, it will most likely trigger a problem when doing so. > > "most likely"? > how about "probably"? > "possibly"? > now about "might produce substandard results"? Well, I guess we can quibble about the amount of likelihood. But the qualitative difference between warnings and style warnings seems clear: Warnings may have undefined consequences or may produce run-time errors, while style warnings are about conforming code that executes fine, just not optimal in some subjective respect. See the entry for the condition type style-warning in the spec. > are you saying that any warning which should not terminate a build > should be a style warning? I guess that's the intended meaning. > what's the semantic (as opposed to behavioral) difference between a > warning and a continuable error then? If a continuable error is successfully continued, then it's not an error, and should not be reported as either an error or a warning. All IMHO, of course... Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
|
Pages: 1 Prev: ANUSHKA HOT PICTURES FOR BOLLYWOOD FANS Next: introductory texts for new Lispers |