Subject: Re: Inline Functions (was: Eureka! Lexical bindings can be guaranteed!) From: Erik Naggum <erik@naggum.no> Date: 2000/03/10 Newsgroups: comp.lang.lisp Message-ID: <3161689163232394@naggum.no> * 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