About asdf:*compile-file-failure-behaviour* and its value on SBCL

[Chun Tian (binghe)]

Hi, ASDF developers

I think asdf:*compile-file-failure-behaviour* should never been set to :error, just :warn is good.

CLHS [1] said about COMPILE-FILE's 2nd and 3rd return values:

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

This means, any warnings other than style-warning will cause COMPILE-FILE return T on its third return value. Than every Lisp file which contains a general (WARN "...") form, when compiling, will cause COMPILE-FILE return T on its third return value, and therefore was marked as "failure" (by ASDF).

In current asdf.lisp, asdf:*compile-file-failure-behaviour* was defined as follow:

(defvar *compile-file-failure-behaviour*
(or #+sbcl :error #+clisp :ignore :warn)
"How should ASDF react if it encounters a failure (per the ANSI spec of COMPILE-FILE)
when compiling a file? Valid values are :error, :warn, and :ignore.
Note that ASDF ALWAYS raises an error if it fails to create an output file when compiling.")

I don't know why SBCL here is special, but this definition caused my project (cl-net-snmp 6.0) failed to be compiled by ASDF "only" on SBCL. Just try to put following lines in your ASDF based project and try to build it:

(eval-when (:compile-toplevel)
(warn "xxx"))

you'll find how ludicrous the current setting of asdf:*compile-file-failure-behaviour* are.

Regards,

Chun Tian (binghe)

[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm#compile-file

[Faré]

Post by Chun Tian (binghe)
Hi, ASDF developers
I think asdf:*compile-file-failure-behaviour* should never been set to :error, just :warn is good.

Well, SBCL is known for its anal attitude towards declaring as an
error or failure anything that could be possibly interpreted as such
by the standard, the idea being that a program that works in SBCL
should work anywhere. Traditionally, a warning in SBCL counts as a
failure in compilation.

Post by Chun Tian (binghe)
(eval-when (:compile-toplevel)
 (warn "xxx"))
you'll find how ludicrous the current setting of asdf:*compile-file-failure-behaviour* are.

What about using alexandria:simple-style-warning ? Maybe there should
be a short-hand alexandria:style-warn? Meh. Or if that's what you
want, just format something to the error-output. In any case, it's a
long tradition for SBCL to behave that way, and other library authors,
including I, have accepted that fact. I'm sorry that the answer isn't
completely satisfactory to you. Been there, done that.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
You don't have to like everything about me, but if you don't love me
the way I am, it's not me you love, only some fantasy of yours.

[Chun Tian (binghe)]

Hi, Fare

Thanks you for your explanation ... it seems that you're suggesting a general WARN condition should never been signaled on compile-time.

Most of the compile-time warnings in my program comes from cl-yacc [1], because I'm trying to do LALR parsing for a very ambiguous language called ASN.1 [1], there're 28 Shift/Reduce, and 1 Reduce/Reduce conflicts in my LALR grammar rules and it produce correct result. Fortunately I used a modified version of cl-yacc and directly include it as vendor code (and changed its package), so I can change all these warnings into style-warnings, to make SBCL happy.

There's another compile-time warning in my CLOS related code, something like this:

(defclass a-class ()
((slot :type 'a-subclass)))

(defclass a-subclass (a-class)
())

When compiling the first class definition, SBCL warn that the type A-SUBCLASS haven't been defined (this is true, but I defined it immediately in next form). I think, to make SBCL happy, again, I have to reorder above two definitions, putting the definition of A-SUBCLASS before A-CLASS, and CLOS does support this, using a MOP feature called FORWARDED-REFERENCE-CLASS.

I still don't think these coding styles are wrong according ANSI Common Lisp standards, but if ASDF insist to do so, I have to modify my code.

Regards,

Chun Tian (binghe)

[1] http://www.pps.jussieu.fr/~jch/software/cl-yacc/

在 2011-3-20，07:53， Faré 写道：

Post by Faré

Post by Chun Tian (binghe)
Hi, ASDF developers
I think asdf:*compile-file-failure-behaviour* should never been set to :error, just :warn is good.

Well, SBCL is known for its anal attitude towards declaring as an
error or failure anything that could be possibly interpreted as such
by the standard, the idea being that a program that works in SBCL
should work anywhere. Traditionally, a warning in SBCL counts as a
failure in compilation.

Post by Chun Tian (binghe)
(eval-when (:compile-toplevel)
(warn "xxx"))
you'll find how ludicrous the current setting of asdf:*compile-file-failure-behaviour* are.

What about using alexandria:simple-style-warning ? Maybe there should
be a short-hand alexandria:style-warn? Meh. Or if that's what you
want, just format something to the error-output. In any case, it's a
long tradition for SBCL to behave that way, and other library authors,
including I, have accepted that fact. I'm sorry that the answer isn't
completely satisfactory to you. Been there, done that.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
You don't have to like everything about me, but if you don't love me
the way I am, it's not me you love, only some fantasy of yours.

[Zach Beane]

Post by Chun Tian (binghe)
(defclass a-class ()
((slot :type 'a-subclass)))
(defclass a-subclass (a-class)
())
When compiling the first class definition, SBCL warn that the type
A-SUBCLASS haven't been defined

I can't reproduce. Is this an oversimplification of your actual problem?

Zach

[Chun Tian (binghe)]

Hi, Zach

Sorry, I checked again, it's just a style-warning, ASDF actually won't stop the building process:

* (compile-file "warning")

; compiling file "/Users/binghe/Lisp/src/warning.lisp" (written 20 MAR 2011 09:27:10 AM):
; compiling (IN-PACKAGE :CL-USER)
; compiling (DEFCLASS A-CLASS ...)
; compiling (DEFCLASS A-SUBCLASS ...)
; file: /Users/binghe/Lisp/src/warning.lisp
; in: DEFCLASS A-CLASS
; (DEFCLASS A-CLASS NIL ((SLOT :TYPE A-SUBCLASS)))
; --> PROGN EVAL-WHEN
; ==>
; (LET ()
; (SB-PCL::LOAD-DEFCLASS 'A-CLASS 'STANDARD-CLASS 'NIL
; (LIST
; (LIST* :NAME 'SLOT :READERS 'NIL :WRITERS 'NIL
; :INITARGS 'NIL 'SB-PCL::TYPE-CHECK-FUNCTION
; (SB-INT:NAMED-LAMBDA #
; #
; #
; SB-PCL::VALUE)
; '(:TYPE A-SUBCLASS)))
; (LIST :DIRECT-DEFAULT-INITARGS NIL) 'NIL 'NIL
; '(SLOT) (SB-C:SOURCE-LOCATION) 'NIL))
;
; caught STYLE-WARNING:
; undefined type: A-SUBCLASS
;
; compilation unit finished
; Undefined type:
; A-SUBCLASS
; caught 1 STYLE-WARNING condition


; /Users/binghe/Lisp/src/warning.fasl written
; compilation finished in 0:00:00.017
#P"/Users/binghe/Lisp/src/warning.fasl"
T
NIL

But I still want to change the order to make it better in SBCL:

* (compile-file "warning")

; compiling file "/Users/binghe/Lisp/src/warning.lisp" (written 20 MAR 2011 09:29:21 AM):
; compiling (IN-PACKAGE :CL-USER)
; compiling (DEFCLASS A-SUBCLASS ...)
; compiling (DEFCLASS A-CLASS ...)

; /Users/binghe/Lisp/src/warning.fasl written
; compilation finished in 0:00:00.014
#P"/Users/binghe/Lisp/src/warning.fasl"
NIL
NIL

--binghe

在 2011-3-20，09:06， Zach Beane 写道：

Post by Zach Beane

Post by Chun Tian (binghe)
(defclass a-class ()
((slot :type 'a-subclass)))
(defclass a-subclass (a-class)
())
When compiling the first class definition, SBCL warn that the type
A-SUBCLASS haven't been defined

I can't reproduce. Is this an oversimplification of your actual problem?
Zach

[Nikodemus Siivola]

Post by Zach Beane

Post by Chun Tian (binghe)
(defclass a-class ()
  ((slot :type 'a-subclass)))
(defclass a-subclass (a-class)
  ())
When compiling the first class definition, SBCL warn that the type
A-SUBCLASS haven't been defined

I can't reproduce. Is this an oversimplification of your actual problem?

Me neither, but...

(declaim (optimize safety))

(defclass a-class ()
((slot :type 'a-subclass)))

(defclass a-subclass (a-class)
())

(defmethod foo ((x a-class) y)
(setf (slot-value x 'slot) y))

gives:

; caught WARNING:
; Undefined type 'A-SUBCLASS. The name starts with QUOTE: probably use of a
; quoted type name in a context where the name is not evaluated.

Replace 'a-subclass with a-subclass, and modern (1.0.45.11 or later, I
would guess) SBCL is silent and happy. (Though really SBCL _should_
complain about the quote even without the OPTIMIZE SAFETY and
DEFMETHOD FOO...) :P

Cheers,

-- Nikodemus

[Chun Tian (binghe)]

Hi, Nikodemus

The QUOTE in "'a-subclass" is actually a typo. Actually I'm compiling this in my last post:

(in-package :cl-user)

(defclass a-subclass (a-class)
())

(defclass a-class ()
((slot :type a-subclass)))

I didn't even declaim a (optimize safety) ...

--binghe

在 2011-3-20，09:38， Nikodemus Siivola 写道：

Post by Nikodemus Siivola

Post by Zach Beane

Post by Chun Tian (binghe)
(defclass a-class ()
((slot :type 'a-subclass)))
(defclass a-subclass (a-class)
())
When compiling the first class definition, SBCL warn that the type
A-SUBCLASS haven't been defined

I can't reproduce. Is this an oversimplification of your actual problem?

Me neither, but...
(declaim (optimize safety))
(defclass a-class ()
((slot :type 'a-subclass)))
(defclass a-subclass (a-class)
())
(defmethod foo ((x a-class) y)
(setf (slot-value x 'slot) y))
; Undefined type 'A-SUBCLASS. The name starts with QUOTE: probably use of a
; quoted type name in a context where the name is not evaluated.
Replace 'a-subclass with a-subclass, and modern (1.0.45.11 or later, I
would guess) SBCL is silent and happy. (Though really SBCL _should_
complain about the quote even without the OPTIMIZE SAFETY and
DEFMETHOD FOO...) :P
Cheers,
-- Nikodemus

[Nikodemus Siivola]

The QUOTE in "'a-subclass" is actually a typo.  Actually I'm compiling

Fair enough.

However, if you update your SBCL you will see that the behaviour has
changed a bit.

Cheers,

-- Nikodemus