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.
Post by Hans HübnerJean-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 <
Post by Jean-Claude BeaudoinHello CL pros,
I am trying to figure out the meaning of the inline declaration when the
(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
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
_______________________________________________
pro mailing list
http://common-lisp.net/cgi-bin/mailman/listinfo/pro