From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: Inline Functions (was: Eureka! Lexical bindings can be guaranteed!)
Date: 2000/03/10
Message-ID: <3161689163232394@naggum.no>#1/1
X-Deja-AN: 595710898
References: <gat-0603001441540001@milo.jpl.nasa.gov> <8a2naf$e4v$1@nnrp1.deja.com> <38C4EE83.AF3BDA64@pindar.com> <8a2t3p$hpv$1@nnrp1.deja.com> <8a32uj$m10$1@nnrp1.deja.com> <8a351o$nff$1@nnrp1.deja.com> <38C618C5.F0DC4A8C@simplex.nl> <vcdsny1mshp.fsf@csusza.math.bme.hu> <8a6d94$j2s$1@news.campuscwix.net> <38C806F8.4924@synquiry.com> <3161625123385591@naggum.no> <952640664257@NewsSIEVE.cs.bonn.edu> <3161640508185948@naggum.no> <38C924D6.478F0151@fisec.com>
mail-copies-to: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: newsmaster@eunet.no
X-Trace: oslo-nntp.eunet.no 952700760 11965 195.0.192.66 (10 Mar 2000 15:06:00 GMT)
Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5
Mime-Version: 1.0
NNTP-Posting-Date: 10 Mar 2000 15:06:00 GMT
Newsgroups: comp.lang.lisp

* Robert Monfera <monfera@fisec.com>
| 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.

#:Erik