[pro] Meaning of "inline" when applied to a generic function?

[Steve Haflich]

Hans is correct.

In more detail, there are some liabilities of the late-binding strategies
that pervade Common Lisp.  If you declaim a function to be inlined, then
you are promising that you will never change it.  While a very smart
implementation could track all the other functions that have inlined that
function, and automatically recompile them, I'm unaware of any
implementation that has provided the mass of bookkeeping this would require.

A generic-function is unlike a regular function in that it has an
implementation that is typically distributed across many top-level forms,
and often distributed across many source files.  This makes the bookkeeping
all the more dificult.

Some may remember ultimately unsuccessful Apple's Newton project in the
late 1990's.  During part of that project they intended the major platform
programming language to be Dylan, which was recognized as a Lisp derivative
benefitting from the recent completion of ANSI CL standard but with a
number of new ideas.  (It was extremely disappointing that Apple eventually
decided to use C syntax rather than Lisp, because that makes macros nearly
impossible.)  Dylan was ultimately unsuccessful -- mo mature
implementations -- and abandoned in favor of C++.

But Dylan had one really great potential feature CL lacks:  It has
protocols for declaring a class tree of a gf to be sealed.  That was a
promise that these entities would never after be modified, which include
extensions!  Once a bunch of stuff has been sealed, a "block compiler"
could in principle (and probably also in practice) walk over an entire
application and do lots of inlining and degenerifying of function calls,
without changing the semantics of a correctly-declared program.  Sealing is
something I would like to have seen added to CL, but machines are so fast
these days that inlining and degenerifying aren't what the Lisp market is
concerned about these days.



On Thu, Jul 10, 2014 at 9:20 AM, Hans Hübner <hans.huebner at gmail.com> wrote:

> Jean-Claude,
>
> you can expect your compiler to ignore your "inline" declaration.  Or do
> something else with it.  It is just a hint. [1]
>
> A sufficiently smart compiler might use compile-time type inference to
> find a method matching some set of argument types and then replace the
> function invocation by the body of that method.  To me, it appears to be
> questionable whether such a smart compiler would depend on inline
> declarations.
>
> I am just a user, though, and maybe one of the compiler writers on this
> list want to add some of the fine points surrounding this :)
>
> -Hans
>
> [1] http://clhs.lisp.se/Body/d_inline.htm
>
>
> 2014-07-10 0:00 GMT+02:00 Jean-Claude Beaudoin <
> jean.claude.beaudoin at gmail.com>:
>
>> Hello CL pros,
>>
>> I am trying to figure out the meaning of the inline declaration when the
>> so qualified function happens to be a generic function. As in:
>>
>> (declaim (inline foo))
>> (defgeneric foo (a b))
>>
>> What can be expected of a compiler when it then faces a call to foo while
>> the above is in effect?
>>
>> Is this an obvious no-op or did some find something useful to do in such
>> a context?
>>
>> Thanks for your help,
>>
>> JCB
>>
>>
>> _______________________________________________
>> pro mailing list
>> pro at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>>
>>
>
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20140710/a5cc1a18/attachment.html>