sbcl seems to by having trouble determining how many values
the following code returns. It's generating a note that says
"Return type not fixed values".
Here's the code, with the compiler messages after it:
http://paste.lisp.org/display/53042
docellsbut iterates through all the cells of a list except
the last one, and the code after the last LET is added in
an annotation to the paste. The only way it can return is
through an explicit (return).
I know a note isn't really serious as warnings and errors are,
but how else can the code return except through the explicit
return commands? After getting the note, I changed a simple
(return) to the block + return-from, but it didn't help.
I guess that makes sense, since LOOP already defines a block,
but then where is the compiler getting confused?
--
Dan
www.prairienet.org/~dsb/
On Dec 26, 4:17 am, Dan Bensen <··········@cyberspace.net> wrote:
> sbcl seems to by having trouble determining how many values
> the following code returns. It's generating a note that says
> "Return type not fixed values".
> Here's the code, with the compiler messages after it:http://paste.lisp.org/display/53042
The note is related to the STATUS function. If efficiency is really
important to you here, try to declare the return type of USABILITY
(e.g. (FUNCTION * (VALUES T &OPTIONAL)).
> On Dec 26, 4:17 am, Dan Bensen <··········@cyberspace.net> wrote:
>> sbcl seems to by having trouble determining how many values
>> the following code returns. It's generating a note that says
>> "Return type not fixed values".
>> Here's the code, with the compiler messages after it:http://paste.lisp.org/display/53042
········@tochka.ru wrote:
> The note is related to the STATUS function. If efficiency is really
> important to you here, try to declare the return type of USABILITY
> (e.g. (FUNCTION * (VALUES T &OPTIONAL)).
Thanks for answering. Actually, performance is important, but
I would also like to know why the compiler can't figure out
how many values USABILITY returns. There's nothing in it that
returns multiple values. It returns either NIL or a keyword.
--
Dan
www.prairienet.org/~dsb/
On Dec 26, 9:23 am, Dan Bensen <··········@cyberspace.net> wrote:
> >> Here's the code, with the compiler messages after it:http://paste.lisp.org/display/53042
> I would also like to know why the compiler can't figure out
> how many values USABILITY returns. There's nothing in it that
> returns multiple values. It returns either NIL or a keyword.
Hard to say without its code. But if USABILITY is defined in another
file and not proclaimed INLINE, the even when the compiler can infer
its type, it still cannot use it, because you can redefine the
function at any time.
> On Dec 26, 9:23 am, Dan Bensen <··········@cyberspace.net> wrote:
>>>> Here's the code, with the compiler messages after it:http://paste.lisp.org/display/53042
>> I would also like to know why the compiler can't figure out
>> how many values USABILITY returns.
········@tochka.ru wrote:
> Hard to say without its code. But if USABILITY is defined in another
> file and not proclaimed INLINE, the even when the compiler can infer
> its type, it still cannot use it, because you can redefine the
> function at any time.
Wow, inlining USABILITY worked. I can hardly believe it.
Mostly because I still don't understand how this situation
is different from any other macro calling any other function,
or how the flet STATUS would make a difference. Thanks for
the help, though.
Dan Bensen wrote:
>> On Dec 26, 9:23 am, Dan Bensen <··········@cyberspace.net> wrote:
>>>>> Here's the code, with the compiler messages after
>>>>> it:http://paste.lisp.org/display/53042
>>> I would also like to know why the compiler can't figure out
>>> how many values USABILITY returns.
>
> ········@tochka.ru wrote:
>> Hard to say without its code. But if USABILITY is defined in another
>> file and not proclaimed INLINE, the even when the compiler can infer
>> its type, it still cannot use it, because you can redefine the
>> function at any time.
>
> Wow, inlining USABILITY worked. I can hardly believe it.
> Mostly because I still don't understand how this situation
> is different from any other macro calling any other function,
> or how the flet STATUS would make a difference. Thanks for
> the help, though.
In lisp, its perfectly legal to redefine a function, even after it has
been used elsewhere, and have the new definition take effect
everywhere. Thus, while the compiler knows perfectly well how many
values this instantiation of USABILITY might return, it doesn't know
what the next USABILITY might do.
FLET is different. Since it has lexical scope, there is no
possibility for an FLET function to be redefined; any redefinition
will occur in another lexical scope; thus more aggressive
optimizations are possible.
INLINE essentially marks a function as unchanging; the compiler is
free to hard-code the current function into all its usage sites. If a
new definition comes around, calling code may not change until it too
is recompiled. Thus INLINE allows dynamic functions to employ the
same optimizations as FLET functions. Unlike macros, an inline
function does not require code expansion at the call site.
Clearer?
- Daniel
> Dan Bensen wrote:
>> I still don't understand how this situation
>> is different from any other macro calling any other function,
>> or how the flet STATUS would make a difference.
D Herring wrote:
> In lisp, its perfectly legal to redefine a function ...
> FLET is different. Since it has lexical scope, there is no possibility
> for an FLET function to be redefined; any redefinition will occur in
> another lexical scope; thus more aggressive optimizations are possible.
>
> INLINE essentially marks a function as unchanging; the compiler is free
> to hard-code the current function into all its usage sites. If a new
> definition comes around, calling code may not change until it too is
> recompiled. Thus INLINE allows dynamic functions to employ the same
> optimizations as FLET functions.
Awesome, thanks a lot.
--
Dan
www.prairienet.org/~dsb/