Python syntax in Lisp and Scheme

Kaz Kylheku kaz at ashi.footprints.net
Tue Oct 14 19:16:52 EDT 2003


Matthias Blume <find at my.address.elsewhere> wrote in message news:<m1k777n2i2.fsf at tti5.uchicago.edu>...
> kaz at ashi.footprints.net (Kaz Kylheku) writes:
> 
> > Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote in message news:<pan.2003.10.13.21.26.56.715704 at knm.org.pl>...
> > > On Mon, 13 Oct 2003 13:51:22 -0700, Kaz Kylheku wrote:
> > > 
> > > > Secondly, it would be unoptimizeable. The result of evaluating a
> > > > lambda expression is an opaque function object. It can only be called.
> > > 
> > > This is not true. When the compiler sees the application of a lambda,
> > > it can inline it and perform further optimizations, fusing together
> > > its arguments, its body and its context.
> > 
> > Kindly keep in mind the overall context of the discussion, which is
> > HOF's versus macros. The closures being discussed are ones passed down
> > into functions. Those closures typically cannot be inlined, except
> > under very special circumstances taken advantage of by a compiler with
> > very smart global optimizations.
> 
> If a macro works in a particular situation, then any equivalent HOF
> can be inlined there as well.  Granted, not all compilers will
> actually do so, but the possibility trivially exists.  This does not
> depend on "very smart" global optimizations.

That is a case of bringing all of the function into the present
context so it can be mixed with the closures manually created there.

A macro controls how much material is inlined and how much isn't.

A macro can have its own binary interface between the expanded
material and some material in a library that is associated with the
macro.

The macro decides what forms need to be made into a closure that is
passed to the library and which are not.

These considerations are important, because in the Lisp world,
programs are dynamically updated while they are running. There are
versioning issues, like keeping new versions of a macro's library
compatible with existing macro-expansions, which won't be re-expanded
and re-compiled when the new code is loaded into an existing
application.




More information about the Python-list mailing list