Some meta-comments concerning comments on proposed Requests for
Implementations (RFIs) and similar documents:

1.  Naming conventions should be consistent.
2.  Names should be self-explanatory and reasonably short, but not too
    short.
3.  Names that have a history of use should not be changed to mean
    something other than their traditional denotation.
4.  The name of a procedure does not matter much unless compilers are
    likely to generate inline code for it.
5.  Procedures that merely compose other procedures are often useful.
6.  Obvious omissions should be remedied.
7.  Less obvious omissions should probably go into a separate proposal.

Will

This one confuses me.  What does the name have to do with code generation?

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.

Barry Margolin:

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

A thing that a good optimizing compiler could do if it compiled a
program that didn't have a REPL in its finished form (such as any
standard-type application) would be to observe that no new value
*had* ever been assigned to given variables, and in the absence of
EVAL (which is part of the REPL) no new value could *ever* be
assigned to it.  

So, if/when the code for EVAL is garbage collected as a program
is compiled, it ought to set off a cascade of inlining and other
optimizations that can't happen until EVAL is out of the way.  

I can see indirecting everything through the symbol table while
the user can still redefine stuff, but if I have a program that
is, say, menu-driven like a standard productivity application,
there's no good reason why the finished compiled form of it
ought not have aggressive inlining done.  I shouldn't have to
make any such promises in that case.

                                        Ray