
meta-comments for comments on proposals
Barry Margolin:
Quote:
> >4. The name of a procedure does not matter much unless compilers are
> > likely to generate inline code for it.
> This one confuses me. What does the name have to do with code generation?
I'm sorry I didn't explain that. An ANSI/IEEE Scheme compiler that
compiles parts of a program independently cannot generate inline code
for things like + and CAR without authorization from the programmer.
This authorization usually takes the form of a compiler switch that
affects the generation of code for some fixed set of standard procedures;
the meaning of this switch is that the programmer promises not to assign
a new value to any of those top-level variables.
This connects names to code generation. If the programmer writes
(define first car)
and tells the compiler to generate inline code for the usual procedures,
then CAR will probably be inlined but FIRST won't: The programmer's use
of the compiler switch promises that CAR is never assigned a new value,
but makes no such guarantee about FIRST. A Scheme compiler could allow
the programmer to declare that FIRST won't be assigned either, and some
compilers do, but most programmers aren't going to bother. As a practical
matter, defining FIRST in this way means it won't be inlined.
The name of a procedure that isn't likely to be inlined doesn't matter
very much because a programmer who doesn't like its name can easily write
something like
(define divide partition)
and then use DIVIDE instead of PARTITION without affecting performance in
any way. You can do this with a procedure that is usually inlined, but
doing so can degrade performance.
This connects with the issue of modules in Scheme. Some of the proposals
would allow modules to export variables, which would prevent a compiler
from generating inline code for FIRST as defined above. Some others would
export values instead, or export read-only access to variables; these
module proposals would allow a compiler to generate inline code for FIRST.
Will