Subject: Re: Inline Functions (was: Eureka! Lexical bindings can be guaranteed!)
From: Erik Naggum <>
Date: 2000/03/10
Newsgroups: comp.lang.lisp
Message-ID: <>

* Robert Monfera <>
| As long as the inter-dependency of named functions is known, it would be
| possible to propagate the invalidation of old definitions and recompile
| with the new ones.  This may admittedly lead to avalanche effect, and I
| don't know how to trigger recompilation of closures without some
| heavyweight administration though.

  the granularity that we get for free when redefining normal, non-inlined
  functions should thus be eminently implementable, but there are no such
  systems around.  there aren't even any systems around that automatically
  recompile functions which use macros that have changed, and that's a much
  more acute problem.

  in some circumstances, there's a need to upgrade a bunch of functions to
  the next generation en bloc, preserving calls within the older generation
  to avoid version skew, but this kind of version control is unavailable.

  what makes you think something like what you propose would be available?

| Inlining reduces debuggability, but reporting accuracy is already
| reduced at high speed optimization settings, and inlining built-in
| functions is one of the several existing and valid reasons.

  but users don't generally debug built-in functions.

| Yes, but isn't this effect the same for compiler macros if you use them
| for the same purpose?

  no, and this is the crucial difference between compiler macros and
  inlining.  a compiler macro can decide to punt on the expansion, which
  causes a normal function call.  a compiler macro can also decide to
  redirect the function call to some other function, or handle part of the
  function call and punt on the rest.  this means that you have make an
  informed choice about the expansion.  you don't have that choice in an
  inlined function's expansion.q

| Do you think that it's too easy to declare a function inlined, and it's a
| good idea to make this non-trivial concept a little harder by having to
| use compiler macros?

  since it doesn't help to declare it inline in Allegro CL, I haven't
  noticed the problem, and in any case, I agree with the decision not to
  honor inline declarations.  languages that require such features are
  typically unable to provide meaningful alternatives -- something Common
  Lisp actually does.