From: Paul B. <pb...@ol...> - 2013-06-26 16:21:48
|
Hello all, Thank you for the comments on my supposed bug. I had hoped you could have been spared the exercise of pointing my problem, but maybe the message I sent was not received. I'll try to be more observant in the future and not send in my typos as bugs. I placed my return message at the bottom of this message. I do, however, have a gripe with the sbcl compiler. The fact that the faulty code would compile even though it had errors is bothersome. I'm currently using sbcl-1.1.8 on a 64-bit Linux platform, but I had sbcl-1.1.7 installed just previously and it also compiled the faulty code. Maybe my error is not a common error, but it seems some checks should be made for such silliness in case a dummy like me should happen along again. I spent a long time looking for the problem in that lisp file and I continually overlooked that misplaced right-paren. It was only after I noticed in one of the back trace items of the debugger that those two errant slots were located separately from the other slots that I got the clue to look at why that was so. I moved the paren from its bad location to its proper location and the problem was solved. If there were proper checks in the compiler, all of my time spent looking for the problem would have been saved as well as the time you guys spent in pointing out my typo. That's the end of my rant, so now I'll go away and be quiet. Thanks again for taking the time to look at my supposed bug, Paul Bowyer -------- Original Message -------- Subject: Re: Your message to Sbcl-bugs awaits moderator approval Date: Sat, 22 Jun 2013 07:36:09 -0700 From: Paul Bowyer <pb...@ol...> To: sbc...@li... On 06/15/2013 08:48 AM, sbc...@li... wrote: > Your mail to 'Sbcl-bugs' with the subject > > I'm uncertain if this is a bug or just something I'm doing > incorrectly > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > https://lists.sourceforge.net/lists/confirm/sbcl-bugs/1a12299baca6c9b2cceab4a113e07995afb9509b > > Hello Sbcl-bugs list, Please disregard my original message on this subject. I discovered MY error (which was a long un-noticed typo) in the class definition. I don't know when I'll get past making those kinds of errors, but I'll keep trying to improve. Paul Bowyer |
From: Christophe R. <cs...@ca...> - 2013-06-26 18:56:22
|
Paul Bowyer <pb...@ol...> writes: > I do, however, have a gripe with the sbcl compiler. The fact that the > faulty code would compile even though it had errors is bothersome. Well, this is a bit more subtle, but: the code is not /a priori/ faulty. The issue here is that in the particular case of defclass, and a few other defining forms mostly related to CLOS, the operators are extensible: it is possible to define metaclasses such that arbitrary extra information can be passed after the slots list. So in this case: (defclass clx-class (standard-class) ((forgd :initarg forgd) (grps :initarg grps))) (defmethod sb-mop:validate-superclass ((c clx-class) (s standard-class)) t) (defclass clx-window () () (:metaclass clx-class)) (defclass clx-entry-dialog (clx-window) ((par-inst :accessor par-inst :initarg :parent-instance) (wnttl :accessor wnttl :initform nil :initarg :win-title) (vinfo :accessor vinfo :initform nil :initarg :var-info) (varlst :accessor varlst :initform nil :initarg :var-list) (tab-idx :accessor tab-idx :initform 1 :initarg :tab-index)) (forgd :accessor forgd #||:initform *white* :initarg :foreground||# ) (grps :accessor grps #||:initform nil :initarg :groups||# ) (:metaclass clx-class)) is legal, compiles, and the clx-entry-dialog class can be instantiated. Now, it might be possible to determine the conditions under which no unknown extension arguments to defclass are legal, and it might also be possible to determine them sufficiently confidently that it would be practical to give an earlier warning when encountering them in the circumstances such as in your initial message. But it's not completely trivial, and this might be one of the cases where a little bit of bother for a relative newcomer, unfortunate though it might be, is something that has to be endured. (If you were motivated enough to remove the bother for the next person, I'd suggest first statically computing the valid initialization arguments for STANDARD-CLASS and then emitting a warning at DEFCLASS-expansion-time if there are initialization arguments generated that are not in that set.) Best wishes, Christophe |
From: Paul B. <pb...@ol...> - 2013-06-26 22:02:41
|
On 06/26/2013 11:56 AM, Christophe Rhodes wrote: > Paul Bowyer <pb...@ol...> writes: > >> I do, however, have a gripe with the sbcl compiler. The fact that the >> faulty code would compile even though it had errors is bothersome. > Well, this is a bit more subtle, but: the code is not /a priori/ faulty. > The issue here is that in the particular case of defclass, and a few > other defining forms mostly related to CLOS, the operators are > extensible: it is possible to define metaclasses such that arbitrary > extra information can be passed after the slots list. > > So in this case: > > (defclass clx-class (standard-class) > ((forgd :initarg forgd) > (grps :initarg grps))) > > (defmethod sb-mop:validate-superclass ((c clx-class) (s standard-class)) > t) > > (defclass clx-window () > () > (:metaclass clx-class)) > > (defclass clx-entry-dialog (clx-window) > ((par-inst :accessor par-inst :initarg :parent-instance) > (wnttl :accessor wnttl :initform nil :initarg :win-title) > (vinfo :accessor vinfo :initform nil :initarg :var-info) > (varlst :accessor varlst :initform nil :initarg :var-list) > (tab-idx :accessor tab-idx :initform 1 :initarg :tab-index)) > (forgd :accessor forgd #||:initform *white* :initarg :foreground||# ) > (grps :accessor grps #||:initform nil :initarg :groups||# ) > (:metaclass clx-class)) > > is legal, compiles, and the clx-entry-dialog class can be instantiated. > > Now, it might be possible to determine the conditions under which no > unknown extension arguments to defclass are legal, and it might also be > possible to determine them sufficiently confidently that it would be > practical to give an earlier warning when encountering them in the > circumstances such as in your initial message. But it's not completely > trivial, and this might be one of the cases where a little bit of bother > for a relative newcomer, unfortunate though it might be, is something > that has to be endured. (If you were motivated enough to remove the > bother for the next person, I'd suggest first statically computing the > valid initialization arguments for STANDARD-CLASS and then emitting a > warning at DEFCLASS-expansion-time if there are initialization arguments > generated that are not in that set.) > > Best wishes, > > Christophe > Hello Christophe, Thanks for the explanation. I see that it might be more trouble than it's worth to add checks to the class definition to catch silly errors like mine. Maybe after I get more experience with lisp in general and sbcl in particular, I might try your suggestion with STANDARD-CLASS just to see how much effort that entails. Paul Bowyer |