From: Edi W. <ed...@ag...> - 2007-02-10 22:24:28
|
This is with SBCL 1.0.2 on Windows, but I think it applies to other platforms as well: Suppose I have this in a Lisp source file: (defun foo (x y) (+ x y)) (defun bar (x) (foo x)) If in SLIME I press C-c C-c (slime-compile-defun) for the first and then for the second definition, I don't get any warnings. Is that on purpose? Wouldn't it be nice if SBCL warned about the wrong number of arguments for FOO in BAR's definition like, say, LispWorks does? (Not related to SLIME - I get the same result if I work directly in an SBCL console window. And I tried this without a ~/.sbclrc file.) Thanks, Edi. |
From: Christophe R. <cs...@ca...> - 2007-02-10 23:01:28
|
Edi Weitz <ed...@ag...> writes: > Suppose I have this in a Lisp source file: > > (defun foo (x y) > (+ x y)) > > (defun bar (x) > (foo x)) > > If in SLIME I press C-c C-c (slime-compile-defun) for the first and > then for the second definition, I don't get any warnings. Is that on > purpose? Wouldn't it be nice if SBCL warned about the wrong number of > arguments for FOO in BAR's definition like, say, LispWorks does? I don't know. On the one hand, this is usually a programmer error. On the other hand, it is explicitly not an error until BAR is called, and even then only if BAR has not been redefined in the meantime. If, instead of doing C-c C-c or entering individual forms at the repl, you compiled the file containing your two forms (as you say you have a file), then SBCL will give you the warning, as under those circumstances SBCL is allowed to assume that the call to FOO within BAR always refers to the FOO defined in the same file (see CLHS 3.2.2.3). Cheers, Christophe |
From: Edi W. <ed...@ag...> - 2007-02-11 20:15:32
|
On Sat, 10 Feb 2007 23:01:17 +0000, Christophe Rhodes <cs...@ca...> wrote: > I don't know. On the one hand, this is usually a programmer error. > On the other hand, it is explicitly not an error until BAR is > called, and even then only if BAR has not been redefined in the > meantime. Hmmm. You're technically 100% right, no doubt. But still, SBCL's behaviour is not very helpful IMHO. (By which I implictly admit that I think the compiler should help the programmer and not show him that it knows better.) I usually see a lot of (style) warnings from SBCL for things that also explicitly aren't errors, but the warnings are there nevertheless.[*] I think it is safe to say that SBCL has one of the chattiest CL compilers around - even if you don't count optimization notes. Why it decides not to warn in this particular case is beyond me. Anyway - just my 0.02 Euros... Cheers, Edi. [*] - "The variable X is defined but never used." - "undefined variable: Y" - "implicitly creating new generic function BAR" - warnings about not following the *FOO* convention for specials - etc. |
From: <wil...@ai...> - 2007-02-11 21:14:42
|
On Sun, Feb 11, 2007 at 09:14:59PM +0100, Edi Weitz wrote: > On Sat, 10 Feb 2007 23:01:17 +0000, Christophe Rhodes <cs...@ca...> wrote: > > I don't know. On the one hand, this is usually a programmer error. > > On the other hand, it is explicitly not an error until BAR is > > called, and even then only if BAR has not been redefined in the > > meantime. > > Hmmm. You're technically 100% right, no doubt. But still, SBCL's > behaviour is not very helpful IMHO. (By which I implictly admit that > I think the compiler should help the programmer and not show him that > it knows better.) I usually see a lot of (style) warnings from SBCL > for things that also explicitly aren't errors, but the warnings are > there nevertheless.[*] > > I think it is safe to say that SBCL has one of the chattiest CL > compilers around - even if you don't count optimization notes. Why it > decides not to warn in this particular case is beyond me. Anyway - > just my 0.02 Euros... > [*] - "The variable X is defined but never used." > - "undefined variable: Y" > - "implicitly creating new generic function BAR" > - warnings about not following the *FOO* convention for specials > - etc. Yep. I hope this isn't a duplicate, but it doesn't seem to've shown up either on my mailreader or on gmane, so here's what I wrote about an earlier round of this: On Sat, Feb 10, 2007 at 11:01:17PM +0000, Christophe Rhodes wrote: > Edi Weitz <ed...@ag...> writes: > > > Suppose I have this in a Lisp source file: > > > > (defun foo (x y) > > (+ x y)) > > > > (defun bar (x) > > (foo x)) > > > > If in SLIME I press C-c C-c (slime-compile-defun) for the first and > > then for the second definition, I don't get any warnings. Is that on > > purpose? Wouldn't it be nice if SBCL warned about the wrong number of > > arguments for FOO in BAR's definition like, say, LispWorks does? > > I don't know. On the one hand, this is usually a programmer error. > On the other hand, it is explicitly not an error until BAR is called, > and even then only if BAR has not been redefined in the meantime. It looks to me as though ANSI "3.2.5 Exceptional Situations in the Compiler" effectively forbids us from giving a full WARNING but encourages us to give a STYLE-WARNING... > If, instead of doing C-c C-c or entering individual forms at the repl, > you compiled the file containing your two forms (as you say you have a > file), then SBCL will give you the warning, as under those > circumstances SBCL is allowed to assume that the call to FOO within > BAR always refers to the FOO defined in the same file (see CLHS > 3.2.2.3). ...except, yes, full WARNING seems appropriate when compiled in the same unit. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C "Faced with the choice between changing one's mind and proving that there is no need to do so, almost everybody gets busy on the proof." -- J. K. Galbraith |
From: Thomas F. B. <tbu...@gm...> - 2007-02-12 09:47:24
|
On 2/10/07, Edi Weitz <ed...@ag...> wrote: > This is with SBCL 1.0.2 on Windows, but I think it applies to other > platforms as well: > > Suppose I have this in a Lisp source file: > > (defun foo (x y) > (+ x y)) > > (defun bar (x) > (foo x)) > > If in SLIME I press C-c C-c (slime-compile-defun) for the first and > then for the second definition, I don't get any warnings. Is that on > purpose? Wouldn't it be nice if SBCL warned about the wrong number of > arguments for FOO in BAR's definition like, say, LispWorks does? If you set sb-ext:*derive-function-types* to t, you'll get a style-warning in this case. You'll generally get some not-quite-ansi behavior, because you're telling the compiler that whatever the type inferencer comes up with for a function will continue to be valid later. I generally work in this mode, because the compiler tends to warn you when you have an interface mismatch or change. |
From: Edi W. <ed...@ag...> - 2007-02-12 11:20:23
|
On Mon, 12 Feb 2007 10:47:18 +0100, "Thomas F. Burdick" <tbu...@gm...> wrote: > If you set sb-ext:*derive-function-types* to t, you'll get a > style-warning in this case. You'll generally get some > not-quite-ansi behavior, because you're telling the compiler that > whatever the type inferencer comes up with for a function will > continue to be valid later. I generally work in this mode, because > the compiler tends to warn you when you have an interface mismatch > or change. Thanks, that's good to know. |