Steel Bank Common Lisp

Edi Weitz <edi@...> 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

On Sat, 10 Feb 2007 23:01:17 +0000, Christophe Rhodes <csr21@...> 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.

On Sun, Feb 11, 2007 at 09:14:59PM +0100, Edi Weitz wrote:
> On Sat, 10 Feb 2007 23:01:17 +0000, Christophe Rhodes <csr21@...> 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 <edi@...> 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 <william.newman@...>
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

On 2/10/07, Edi Weitz <edi@...> 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.

On Mon, 12 Feb 2007 10:47:18 +0100, "Thomas F. Burdick" <tburdick@...> 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.