Issue: LOAD-TIME-EVAL (Version 1)

[Masinter.pa@Xerox.COM]

This issue was just submitted by Jim Kempf. I made some minor edits to
his submission (e.g. fundef => function definition)  but it is otherwise
as submitted.

My comments:

I think the test case needs to be fixed up so that it can stand alone
(i.e., be a fragment of code that could, for example, become a part of a
diagnostic suite). 

Does this have any justification other than the Common Lisp Object
System? (I think it does, but they aren't mentioned here.) 

Other than that, I think it looks OK. What do you think?

!
Issue:           SHARP-COMMA-SPECIAL-FORM
References: #, (p. 356),  (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category:     ADDITION
Edit history: Version 1 submitted 6/6/87, James Kempf.

Problem description:

The specification of #, (load time evaluation) in Common Lisp does not
provide a means of generating code using macros which can perform load
time evaluation within embedded forms. Load time evaluation at the top
level is possible using (EVAL-WHEN (LOAD) ... ), but there is no way
arrange for a form generated by a macro to be evaluated at load time
because #, is a reader macro and code generated by macros is not
processed by the reader.

Proposal (SHARP-COMMA-SPECIAL-FORM:LOAD-TIME-EVAL):

When interpreted or compiled in memory, LOAD-TIME-EVAL evaluates its
argument immediately. When being compiled as part of a file compilation,
LOAD-TIME-EVAL arranges for its argument to be evaluated when the file
is loaded. LOAD-TIME-EVAL can be used anywhere, and is not restricted to
being a top level form, nor to code being processed by the reader.

Test Case: 

(defmacro call-method (spec &rest args)
	  `(apply
	      (load-time-eval 
		(load-time-look-up-method ,spec))
	      ,args)))

This macro generates code which applies a function which is determined
at load time. It is a summary of some more complex code in the
CommonObjects object-oriented language extension built on the Common
Lisp Object System.

Rationale:

Currently, there is no way to arrange for load time evaluation within
macro generated code. This capability is required for object-oriented
extensions of Common Lisp, since often neither the name nor the function
definition object is known until load time. It is particularly useful
for optimizing calls to superclass methods.

Current practice:

Currently, every version of Common Lisp is required to implement
compiler hooks for #, so the primitives for implementing LOAD-TIME-EVAL
should exist. 

Adoption Cost: 

The cost to implementors should be relatively slight, considering
primitives for implementing #, can be resued. Many implementations of
Common Lisp may have LOAD-TIME-EVAL available as public domain code, if
they done it for Portable Common Loops.

Cost of non-adoption: 

Optimization of CALL-NEXT-METHOD in the Common Lisp Object System will
be implementation dependent, and other languages built on the metaclass
kernel wanting to optimize calls to superclass methods will have no
specified, portable way of doing so.

Benefits: 

Optimization of calls on superclass methods in the Common Lisp Object
System will have a portable hook, which will make transporting code
easier. If the problem is left as it is, each vendor could solve the
problem differently, encouraging nonportable code.

Conversion Cost:

Extremely low. Most users will be completely unaffected.

Esthetics:

The proposal fills a hole in the spectrum of alternatives for achieving
load time evaluation. Currently, code which is read by the reader can
arrange for it to be done, as can top level code, but embedded code
cannot.

Discussion:

There seems to be little disagreement on this, as far as can be
determined at this date. The Portable Common Loops implementation
encourages vendors to add this, to facilitate calling superclass methods
directly, and there has not been any negative reaction so far. It will
certainly help make the Common Lisp Object System easier to implement,
and easier to extend.