<div dir="ltr">Hans is correct.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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++.</div>
<div><br></div><div>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.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 10, 2014 at 9:20 AM, Hans Hübner <span dir="ltr"><<a href="mailto:hans.huebner@gmail.com" target="_blank">hans.huebner@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Jean-Claude,</div><div><br></div><div>you can expect your compiler to ignore your "inline" declaration.  Or do something else with it.  It is just a hint. [1]</div>
<div><br>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.</div>


<div><br></div><div>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 :)</div><div><br></div><div>-Hans</div><div><br></div><div>[1] <a href="http://clhs.lisp.se/Body/d_inline.htm" target="_blank">http://clhs.lisp.se/Body/d_inline.htm</a></div>


</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-10 0:00 GMT+02:00 Jean-Claude Beaudoin <span dir="ltr"><<a href="mailto:jean.claude.beaudoin@gmail.com" target="_blank">jean.claude.beaudoin@gmail.com</a>></span>:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div><div><div><div>Hello CL pros,<br><br></div>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:<br>


<br></div>
(declaim (inline foo))<br></div>(defgeneric foo (a b))<br><br></div>What can be expected of a compiler when it then faces a call to foo while the above is in effect?<br><br></div>Is this an obvious no-op or did some find something useful to do in such a context?<br>



<br></div>Thanks for your help,<br><br></div>JCB<br><br></div>
<br></div></div>_______________________________________________<br>
pro mailing list<br>
<a href="mailto:pro@common-lisp.net" target="_blank">pro@common-lisp.net</a><br>
<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
pro mailing list<br>
<a href="mailto:pro@common-lisp.net">pro@common-lisp.net</a><br>
<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
<br></blockquote></div><br></div>