Inline and Notinline (Was: Re: Core foundation of Common Lisp (not pure Lisp))

From: Rahul Jain (rjain_at_nyct.net)
Date: 01/07/05 

Date: Thu, 06 Jan 2005 23:47:27 -0500

Duane Rettig <duane@franz.com> writes:

> Rahul Jain <rjain@nyct.net> writes:
>
>> "Steven M. Haflich" <smh_no_spiced_ham@alum.mit.edu> writes:
>>
>> > It is more relevant to underatand why the following definition would
>> > not have resulted in a working CL implementation:
>> >
>> > (defun not (x)
>> > (declare (notinline not))
>> > (not x))
>
> Heh; I wasn't sure why Steve made this statement - it seemed
> obvious. Now I understand why...
>
>> Are you sure? "Special-forming" of CL operators is not covered under
>> inlining, is it?
>
> Special-forms has nothing to do with this example. Not is not a
> special operator.

That's why I quoted it. It's treated as a special form in that it is
compiled in a primitive way, the same way that macros are allowed to be
implemented as special-forms but must provide a macro-function.

>> I think the undefined behavior of redefining CL
>> operators leaves the door open to the compiler implementing NOT as a
>> direct assembly operation instead of a full function call. The NOTINLINE
>> declaration would not hurt such an implementation.
>
> The redefinition of CL operators is undefined, but the requirement
> to obey the notinline declaration is not. It is not even clear
> that the form given was placed in a package that uses the CL package.
> What is clear, is that the example _must_ result in an infinite
> loop/recursion in a conforming lisp.

Yikes, looking at the spec I see that quite explicitly. What is
interesting is the requirement that the declaration be obeyed for
_local_ function calls, too. I'm not sure what exactly this is trying to
achieve, because it could be argued that the local function is bound
lexically to the name, and so a redefinition of the surrounding function
would simply create a new function bound lexically to that name. The
binding in the previous function would be unaffected. 

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist