Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!usc!samsung!uunet!mcsun!unido!tub!tubopal!opal!simon
From: simon@packer.UUCP (Simon Leinen)
Newsgroups: comp.lang.lisp
Subject: Re: Linking and MACL (really efficiency of local functions)
Message-ID: <SIMON.89Nov23120357@packer.UUCP>
Date: 23 Nov 89 11:03:57 GMT
References: <21316@brunix.UUCP> <1989Nov20.150510.20700@hellgate.utah.edu>
	<SIMON.89Nov21182043@bear.UUCP>
	<Nov.22.12.11.49.1989.1498@atanasoff.rutgers.edu>
	<31762@news.Think.COM>
Sender: news@tubopal.UUCP
Organization: TU Berlin, Fachbereich 20 (Informatik)
Lines: 32
In-reply-to: barmar@leander.think.com's message of 22 Nov 89 21:44:33 GMT
To:

In article <31762@news.Think.COM> barmar@leander.think.com (Barry Margolin) writes:

   Both Common Lisp implementations I'm familiar with -- Symbolics and
   Lucid -- have names for local functions.  They are named (:INTERNAL
   <parent> <n> <name>), where <parent> is the name of the function
   containing the local definition, <n> is an index used to
   distinguish multiple local functions in the same parent, and <name>
   is an optional name produced when FLET, LABELS, or SYS:NAMED-LAMBDA
   are used (anonymous local functions are just named (:INTERNAL
   <parent> <n>).  You can pass these names to TRACE, DISASSEMBLE,
   etc.

This is what makes local functions expensive: They are called through
a (synthetic) symbol's function cell.  When you use the `production
compiler' of Lucid Lisp, this overhead is avoided.  As Sandra
Loosemore argued, calls to local functions should be *cheaper* than
calls to global functions.

The Lucid implementation often integrates local functions into their
callers, thus eliminating function call overhead *completely*.  This
is the way to do local functions in production compilers: Using them
costs nothing in many cases, and there is no need to write huge
function bodies because of efficiency considerations when you would
rather like to have many small (local) functions.

I agree completely with what Sandra said about use of Common Lisp
constructs and the quality of present Lisp implementations.  Don't
blame every efficiency problem to the language; many `expensive'
features of Lisp can be implemented quite efficiently at the expense
of additional brain work (see Orbit and Lucid Lisp).
-- 
Simon Leinen.