From: Robert G. <rpg...@si...> - 2010-12-26 18:27:30
|
Looking at some macroexpansions, I found what seems to me to be an oddity in SBCL's generation of style warnings: CL-USER> (defun foo (bar baz) (destructuring-bind (a b) bar (declare (ignore baz)) (* a b))) ; in: LAMBDA NIL ; (IGNORE BAZ) ; ; caught STYLE-WARNING: ; declaring unknown variable BAZ to be ignored ; (SB-INT:NAMED-LAMBDA FOO ; (BAR BAZ) ; (BLOCK FOO (DESTRUCTURING-BIND (A B) BAR (DECLARE (IGNORE BAZ)) (* A B)))) ; ==> ; #'(SB-INT:NAMED-LAMBDA FOO ; (BAR BAZ) ; (BLOCK FOO (DESTRUCTURING-BIND (A B) BAR (DECLARE (IGNORE BAZ)) (* A B)))) ; ; caught STYLE-WARNING: ; The variable BAZ is defined but never used. ; ; compilation unit finished ; caught 2 STYLE-WARNING conditions Why is it that SBCL thinks baz is unknown inside the destructuring-bind? I'm not saying that this is a /good/ place for the IGNORE, but it doesn't seem like a place that should be forbidden. Indeed, it seems like there's a more plausible case for such a declaration here: CL-USER> (defun bar (bar baz) (pprint baz) (destructuring-bind (a b) bar (declare (ignore baz)) (* a b))) ; in: LAMBDA NIL ; (IGNORE BAZ) ; ; caught STYLE-WARNING: ; declaring unknown variable BAZ to be ignored ; ; compilation unit finished ; caught 1 STYLE-WARNING condition BAR I have only examined the CLHS for DECLARE and IGNORE, so I may have missed something that would indicate why these warnings are appropriate. If so, my apologies. best, r |
From: Scott L. B. <Sc...@sy...> - 2010-12-26 20:36:06
|
On Sun, Dec 26, 2010 at 10:09 AM, Robert Goldman <rpg...@si...> wrote: > Looking at some macroexpansions, I found what seems to me to be an > oddity in SBCL's generation of style warnings: > > CL-USER> (defun foo (bar baz) > (destructuring-bind (a b) bar > (declare (ignore baz)) > (* a b))) > ; in: LAMBDA NIL > ; (IGNORE BAZ) > ; > ; caught STYLE-WARNING: > ; The variable BAZ is defined but never used. The IGNORE declaration has to go immediately within the binding construct to be effective. In this case that means it has to precede the DESTRUCTURING-BIND. This is a standard CL rule. -- Scott |
From: Robert P. G. <rpg...@si...> - 2010-12-26 22:10:50
|
That is plausible to me, but I couldn't find an authority in the CLHS. Do you have a pointer? Thanks! "Scott L. Burson" <Sc...@sy...> wrote: >On Sun, Dec 26, 2010 at 10:09 AM, Robert Goldman <rpg...@si...> >wrote: >> Looking at some macroexpansions, I found what seems to me to be an >> oddity in SBCL's generation of style warnings: >> >> CL-USER> (defun foo (bar baz) >> (destructuring-bind (a b) bar >> (declare (ignore baz)) >> (* a b))) >> ; in: LAMBDA NIL >> ; (IGNORE BAZ) >> ; >> ; caught STYLE-WARNING: >> ; The variable BAZ is defined but never used. > >The IGNORE declaration has to go immediately within the binding >construct to be effective. In this case that means it has to precede >the DESTRUCTURING-BIND. This is a standard CL rule. > >-- Scott -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. |
From: Scott L. B. <Sc...@sy...> - 2010-12-26 23:22:05
|
On Sun, Dec 26, 2010 at 2:10 PM, Robert P. Goldman <rpg...@si...> wrote: > That is plausible to me, but I couldn't find an authority in the CLHS. Do you have a pointer? > Thanks! Section 3.3.4. -- Scott > "Scott L. Burson" <Sc...@sy...> wrote: > >>On Sun, Dec 26, 2010 at 10:09 AM, Robert Goldman <rpg...@si...> >>wrote: >>> Looking at some macroexpansions, I found what seems to me to be an >>> oddity in SBCL's generation of style warnings: >>> >>> CL-USER> (defun foo (bar baz) >>> (destructuring-bind (a b) bar >>> (declare (ignore baz)) >>> (* a b))) >>> ; in: LAMBDA NIL >>> ; (IGNORE BAZ) >>> ; >>> ; caught STYLE-WARNING: >>> ; The variable BAZ is defined but never used. >> >>The IGNORE declaration has to go immediately within the binding >>construct to be effective. In this case that means it has to precede >>the DESTRUCTURING-BIND. This is a standard CL rule. >> >>-- Scott > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > |
From: Stelian I. <sio...@cd...> - 2010-12-27 00:06:09
|
On Sun, 2010-12-26 at 15:21 -0800, Scott L. Burson wrote: > On Sun, Dec 26, 2010 at 2:10 PM, Robert P. Goldman <rpg...@si...> wrote: > > That is plausible to me, but I couldn't find an authority in the CLHS. Do you have a pointer? > > Thanks! > > Section 3.3.4. I can't seem to find a clause in that section that requires IGNORE declarations to be bound declarations -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib |
From: Robert P. G. <rpg...@si...> - 2010-12-26 23:54:15
|
I looked at that section and I still don't follow. That section distinguishes between free and bound declarations, but it doesn't prohibit free ignore declarations, does it? I admit that I am not sure what the UTILITY of a free ignore declaration would be, but I don't see where they are specifically prohibited. Best, R "Scott L. Burson" <Sc...@sy...> wrote: >On Sun, Dec 26, 2010 at 2:10 PM, Robert P. Goldman ><rpg...@si...> wrote: >> That is plausible to me, but I couldn't find an authority in the >CLHS. Do you have a pointer? >> Thanks! > >Section 3.3.4. > >-- Scott > >> "Scott L. Burson" <Sc...@sy...> wrote: >> >>>On Sun, Dec 26, 2010 at 10:09 AM, Robert Goldman ><rpg...@si...> >>>wrote: >>>> Looking at some macroexpansions, I found what seems to me to be an >>>> oddity in SBCL's generation of style warnings: >>>> >>>> CL-USER> (defun foo (bar baz) >>>> (destructuring-bind (a b) bar >>>> (declare (ignore baz)) >>>> (* a b))) >>>> ; in: LAMBDA NIL >>>> ; (IGNORE BAZ) >>>> ; >>>> ; caught STYLE-WARNING: >>>> ; The variable BAZ is defined but never used. >>> >>>The IGNORE declaration has to go immediately within the binding >>>construct to be effective. In this case that means it has to precede >>>the DESTRUCTURING-BIND. This is a standard CL rule. >>> >>>-- Scott >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. |
From: Scott L. B. <Sc...@sy...> - 2010-12-27 00:50:13
|
On Sun, Dec 26, 2010 at 3:54 PM, Robert P. Goldman <rpg...@si...> wrote: > I looked at that section and I still don't follow. That section distinguishes between free and bound declarations, but it doesn't prohibit free ignore declarations, does it? > > I admit that I am not sure what the UTILITY of a free ignore declaration would be, but I don't see where they are specifically prohibited. I'm not interested in researching the matter further, but I will agree with you that a free IGNORE declaration would be useless. -- Scott > > "Scott L. Burson" <Sc...@sy...> wrote: > >>On Sun, Dec 26, 2010 at 2:10 PM, Robert P. Goldman >><rpg...@si...> wrote: >>> That is plausible to me, but I couldn't find an authority in the >>CLHS. Do you have a pointer? >>> Thanks! >> >>Section 3.3.4. >> >>-- Scott >> >>> "Scott L. Burson" <Sc...@sy...> wrote: >>> >>>>On Sun, Dec 26, 2010 at 10:09 AM, Robert Goldman >><rpg...@si...> >>>>wrote: >>>>> Looking at some macroexpansions, I found what seems to me to be an >>>>> oddity in SBCL's generation of style warnings: >>>>> >>>>> CL-USER> (defun foo (bar baz) >>>>> (destructuring-bind (a b) bar >>>>> (declare (ignore baz)) >>>>> (* a b))) >>>>> ; in: LAMBDA NIL >>>>> ; (IGNORE BAZ) >>>>> ; >>>>> ; caught STYLE-WARNING: >>>>> ; The variable BAZ is defined but never used. >>>> >>>>The IGNORE declaration has to go immediately within the binding >>>>construct to be effective. In this case that means it has to precede >>>>the DESTRUCTURING-BIND. This is a standard CL rule. >>>> >>>>-- Scott >>> >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > |
From: Robert P. G. <rpg...@si...> - 2010-12-27 03:11:14
|
It may or may not be useless, but it seems to trigger an odd style-warning here. I could understand a style warning claiming that the declaration is pointless, but SBCL seems to be claiming that a clearly defined variable is not defined. "Scott L. Burson" <Sc...@sy...> wrote: >On Sun, Dec 26, 2010 at 3:54 PM, Robert P. Goldman ><rpg...@si...> wrote: >> I looked at that section and I still don't follow. That section >distinguishes between free and bound declarations, but it doesn't >prohibit free ignore declarations, does it? >> >> I admit that I am not sure what the UTILITY of a free ignore >declaration would be, but I don't see where they are specifically >prohibited. > >I'm not interested in researching the matter further, but I will agree >with you that a free IGNORE declaration would be useless. > >-- Scott > >> >> "Scott L. Burson" <Sc...@sy...> wrote: >> >>>On Sun, Dec 26, 2010 at 2:10 PM, Robert P. Goldman >>><rpg...@si...> wrote: >>>> That is plausible to me, but I couldn't find an authority in the >>>CLHS. Do you have a pointer? >>>> Thanks! >>> >>>Section 3.3.4. >>> >>>-- Scott >>> >>>> "Scott L. Burson" <Sc...@sy...> wrote: >>>> >>>>>On Sun, Dec 26, 2010 at 10:09 AM, Robert Goldman >>><rpg...@si...> >>>>>wrote: >>>>>> Looking at some macroexpansions, I found what seems to me to be >an >>>>>> oddity in SBCL's generation of style warnings: >>>>>> >>>>>> CL-USER> (defun foo (bar baz) >>>>>> (destructuring-bind (a b) bar >>>>>> (declare (ignore baz)) >>>>>> (* a b))) >>>>>> ; in: LAMBDA NIL >>>>>> ; (IGNORE BAZ) >>>>>> ; >>>>>> ; caught STYLE-WARNING: >>>>>> ; The variable BAZ is defined but never used. >>>>> >>>>>The IGNORE declaration has to go immediately within the binding >>>>>construct to be effective. In this case that means it has to >precede >>>>>the DESTRUCTURING-BIND. This is a standard CL rule. >>>>> >>>>>-- Scott >>>> >>>> -- >>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>>> >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. |
From: Harald Hanche-O. <ha...@ma...> - 2010-12-27 11:35:01
|
["Robert P. Goldman" <rpg...@si...> (2010-12-27 03:11:06 UTC)] > It may or may not be useless, but it seems to trigger an odd style-warning here. I could understand a style warning claiming that the declaration is pointless, but SBCL seems to be claiming that a clearly defined variable is not defined. In some technical sense you have a point, but I am having a hard time imagining a scenario in which the wording of that warning will be genuinely confusing, or even delay the programmer by more than a few seconds in finding out what's wrong with the code. So I don't think it's worth fixing. - Harald |
From: Nikolaus D. <de...@in...> - 2010-12-27 12:11:58
|
Am 27.12.2010 um 12:08 schrieb Harald Hanche-Olsen: > ["Robert P. Goldman" <rpg...@si...> (2010-12-27 03:11:06 UTC)] > >> It may or may not be useless, but it seems to trigger an odd style-warning here. I could understand a style warning claiming that the declaration is pointless, but SBCL seems to be claiming that a clearly defined variable is not defined. > > In some technical sense you have a point, but I am having a hard time imagining a scenario in which the wording of that warning will be genuinely confusing, or even delay the programmer by more than a few seconds in finding out what's wrong with the code. So I don't think it's worth fixing. That is if you know CL well enough to be aware of the restrictions for declare statements. In my opinion compiler warnings/errors should not only serve the expert hacker, but also aid the apprentice in learning the language. (CL especially is not known to be easy / quick to master). Best regards, Niko |
From: Robert G. <rpg...@si...> - 2010-12-27 15:20:45
|
On 12/27/10 Dec 27 -5:08 AM, Harald Hanche-Olsen wrote: > ["Robert P. Goldman" <rpg...@si...> (2010-12-27 03:11:06 UTC)] > >> It may or may not be useless, but it seems to trigger an odd style-warning here. I could understand a style warning claiming that the declaration is pointless, but SBCL seems to be claiming that a clearly defined variable is not defined. > > In some technical sense you have a point, but I am having a hard time imagining a scenario in which the wording of that warning will be genuinely confusing, or even delay the programmer by more than a few seconds in finding out what's wrong with the code. So I don't think it's worth fixing. Hm... I'm not sure that I agree that it's unconfusing. The way I encountered this was from a bug in someone else's macro. I had to know to macroexpand and then guess that the style-warning was misleading. Then I had to spot this misplaced declaration. My guess is that if you encounter this bug, it is very likely to come from macro-generated code, where the programmer can use any help s/he can get to find the bug. I'll take a look and see if I can identify the case, and propose a patch. Any help finding the location would be received with gratitude; I'm not that familiar with the SBCL source layout. cheers, r |
From: Harald Hanche-O. <ha...@ma...> - 2010-12-27 17:03:43
|
[Robert Goldman <rpg...@si...> (2010-12-27 15:20:36 UTC)] > On 12/27/10 Dec 27 -5:08 AM, Harald Hanche-Olsen wrote: > > In some technical sense you have a point, but I am having a hard > time imagining a scenario in which the wording of that warning will > be genuinely confusing, or even delay the programmer by more than a > few seconds in finding out what's wrong with the code. So I don't > think it's worth fixing. > > Hm... I'm not sure that I agree that it's unconfusing. The way I > encountered this was from a bug in someone else's macro. Um, okay, maybe ... > Any help finding the location would be received with gratitude; Like so, perhaps: ; grep -r 'declaring unknown variable .* to be ignored' src src/compiler/ir1tran.lisp: (compiler-style-warn "declaring unknown variable ~S to be ignored" - Harald |
From: Robert G. <rpg...@si...> - 2010-12-27 17:15:11
|
On 12/27/10 Dec 27 -11:03 AM, Harald Hanche-Olsen wrote: > [Robert Goldman <rpg...@si...> (2010-12-27 15:20:36 UTC)] > >> Any help finding the location would be received with gratitude; > > Like so, perhaps: > > ; grep -r 'declaring unknown variable .* to be ignored' src > src/compiler/ir1tran.lisp: (compiler-style-warn "declaring > unknown variable ~S to be ignored" OK, that gets us to this: (defun process-ignore-decl (spec vars fvars) (declare (list spec vars fvars)) (dolist (name (rest spec)) (let ((var (find-in-bindings-or-fbindings name vars fvars))) (cond ((not var) ;; ANSI's definition for "Declaration IGNORE, IGNORABLE" ;; requires that this be a STYLE-WARNING, not a full WARNING. + (compiler-style-warn "declaring unknown variable ~S to be ignored" name)) ;; FIXME: This special case looks like non-ANSI weirdness. ((and (consp var) (eq (car var) 'macro)) ;; Just ignore the IGNORE decl. ) ((functional-p var) (setf (leaf-ever-used var) t)) ((and (lambda-var-specvar var) (eq (first spec) 'ignore)) ;; ANSI's definition for "Declaration IGNORE, IGNORABLE" ;; requires that this be a STYLE-WARNING, not a full WARNING. (compiler-style-warn "declaring special variable ~S to be ignored" name)) ((eq (first spec) 'ignorable) (setf (leaf-ever-used var) t)) (t (setf (lambda-var-ignorep var) t))))) (values)) This raises a couple of questions: 1. Would it be reasonable to change the call marked with "+" to: (compiler-style-warn "Declaring variable ~S to be ignored, but not in the form which defines this variable." name) ? 2. At the FIXME, any reason why there's not a WARN there, something like: (compiler-warn "IGNORE declaration for a macro, ~S, not supported. Skipping this declaration." var) ? Thanks, r |
From: Christopher S. <cs...@dt...> - 2010-12-27 19:50:19
|
"Variable ~S is declared IGNORED but is not bound in this form" |
From: Harald Hanche-O. <ha...@ma...> - 2010-12-27 22:06:47
|
[Christopher Stacy <cs...@dt...> (2010-12-27 19:23:30 UTC)] > "Variable ~S is declared IGNORED but is not bound in this form" Excellent. Proof that bikeshedding isn't always bad. 8-) (http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality for those who don't get the reference.) - Harald |
From: Robert G. <rpg...@si...> - 2010-12-29 16:19:35
|
On 12/27/10 Dec 27 -11:14 AM, Robert Goldman wrote: > On 12/27/10 Dec 27 -11:03 AM, Harald Hanche-Olsen wrote: >> [Robert Goldman <rpg...@si...> (2010-12-27 15:20:36 UTC)] >> >>> Any help finding the location would be received with gratitude; >> >> Like so, perhaps: >> >> ; grep -r 'declaring unknown variable .* to be ignored' src >> src/compiler/ir1tran.lisp: (compiler-style-warn "declaring >> unknown variable ~S to be ignored" > > OK, that gets us to this: > > (defun process-ignore-decl (spec vars fvars) > (declare (list spec vars fvars)) > (dolist (name (rest spec)) > (let ((var (find-in-bindings-or-fbindings name vars fvars))) > (cond > ((not var) > ;; ANSI's definition for "Declaration IGNORE, IGNORABLE" > ;; requires that this be a STYLE-WARNING, not a full WARNING. > + (compiler-style-warn "declaring unknown variable ~S to be ignored" > name)) > ;; FIXME: This special case looks like non-ANSI weirdness. > ((and (consp var) (eq (car var) 'macro)) > ;; Just ignore the IGNORE decl. > ) > ((functional-p var) > (setf (leaf-ever-used var) t)) > ((and (lambda-var-specvar var) (eq (first spec) 'ignore)) > ;; ANSI's definition for "Declaration IGNORE, IGNORABLE" > ;; requires that this be a STYLE-WARNING, not a full WARNING. > (compiler-style-warn "declaring special variable ~S to be ignored" > name)) > ((eq (first spec) 'ignorable) > (setf (leaf-ever-used var) t)) > (t > (setf (lambda-var-ignorep var) t))))) > (values)) > .... > > 2. At the FIXME, any reason why there's not a WARN there, something like: > > (compiler-warn > "IGNORE declaration for a macro, ~S, not supported. Skipping this > declaration." > var) > ? OK, now I understand this better. That case is triggered if you try to IGNORE (or IGNORABLE) a variable introduced by WITH-ACCESSORS (it may be triggered by other code, as well, I don't know). The spec here is a little misleading, because it specifies that you pass a variable-name to with-accessors, but then it implies that this is not actually being used as a variable (and it isn't in SBCL). So, question: would it be reasonable to put a style warning here and, if so, does anyone have a suggestion about how to phrase it? Telling the hapless user that "(SB-SYS:MACRO BODY-SUPP #:G189)" is being declared as ignored might not be helpful.... Thanks, r |
From: Harald Hanche-O. <ha...@ma...> - 2010-12-27 19:17:55
|
[Robert Goldman <rpg...@si...> (2010-12-27 17:14:55 UTC)] > 1. Would it be reasonable to change the call marked with "+" to: > > (compiler-style-warn > "Declaring variable ~S to be ignored, but not in the form which > defines this variable." > name) No, because it seems to imply that the variable is defined elsewhere, which it might not be. I suggest something along the lines of "Declaring variable ~S, not bound in this form, to be ignored" (I have no idea about your other question.) - Harald |
From: Robert G. <rpg...@si...> - 2010-12-27 19:25:56
|
On 12/27/10 Dec 27 -1:17 PM, Harald Hanche-Olsen wrote: > [Robert Goldman <rpg...@si...> (2010-12-27 17:14:55 UTC)] > >> 1. Would it be reasonable to change the call marked with "+" to: >> >> (compiler-style-warn >> "Declaring variable ~S to be ignored, but not in the form which >> defines this variable." >> name) > > No, because it seems to imply that the variable is defined elsewhere, > which it might not be. I suggest something along the lines of > > "Declaring variable ~S, not bound in this form, to be ignored" > > (I have no idea about your other question.) Quite right. That is a much more clear message. best, r |