Re: Issue: LOAD-TIME-EVAL (Version 1)

[Jim Kempf <kempf%hplabsc@hplabs.HP.COM>]

Well, let's see if I can speak to Dave's concerns about the
proposal.

>LOAD-TIME-EVAL is presented as if it did the same thing as sharp-comma,
>but they are rather different.  #, must appear inside a quoted constant,
>at least in any compiler implementation I am familiar with, whereas
>load-time-eval is a form and must not appear inside a quoted constant. 
>This is not a fundamental problem, it's just confusing.

The specification for the semantics of #, is found on pg. 356 of CLtL:

	#,FOO is read as the object resulting from the evaluation
	of the LISP object represented by FOO, which may be the
	printed representation of any LISP object. The
	evaluation is done during the READ process, unless the
	compiler is doing the reading, in which case it is
	arranged that FOO will be evauated when the file
	of compiled code is loaded. The #, syntax performs
	*load-time evaluation* (italics mine) of FOO. By
	contrast, #. (see above) performs a read-time
	evaluation. In a sense, #, is like specifying
	(EVAL LOAD) to EVAL-WHEN, whereas #. is more like
	specifying (EVAL COMPILE). It makes no difference
	when loading interpreted code; when code is to be
	compiled, however, #. specifies compile-time
	evaluation and #, specifies load time evaluation.

Since this description says nothing about having #, be inside quoted
code for the compiler, I guess I don't quite understand the confusion,
or, perhaps, am confused myself about how this fits with the model of #,.
I would agree, however, with the statement that LOAD-TIME-EVAL and
#, are different in that LOAD-TIME-EVAL is a form.

>The remark "Load time evaluation at the top level is possible using
>(EVAL-WHEN (LOAD) ... )" does not make any sense, as what that EVAL-WHEN
>special form actually does is to inhibit evaluation when loading a file
>into the interpreter; it does not cause something to be evaluated at a
>different time.  I think the real lesson to be learned from this little
>slip is that "load time evaluation" is a poor way of describing the
>feature we are trying to get at here; the feature we really want is
>load-time construction of constants.

I agree that a better description of the feature may be load-time
construction of constants; however, in phrasing the proposal, I
was trying to be consistent with CLtL's description of (EVAL-WHEN (LOAD) ...)
specifically (CLtL, pg. 69):

	LOAD specifies that the compiler should arrange to evaluate
	the forms in the body when the compiled file containing the
	EVAL-WHEN form is loaded.

The rest of this section describes Common Lisp's processing model,
into which I was trying to fit this addition.


>It's not crystal clear how many times LOAD-TIME-EVAL evaluates its
>subform and what is done with the result.  I believe the intention is
>that `(foo (load-time-eval (bar))) is roughly like
>`(foo (quote ,(bar))), which explains what is done with the result.
>I'm not happy with the way I just explained it, but can't think of a
>better way.  Can the subform be evaluated more than once in interpreted
>code?

The subform should be evaluated once and only once (i.e. never
not evaluated and never evaluated more than once) in interpreted
code.

>It might be worth discussing the obvious other way of doing this, which
>would be a function called by a macro, instead of a special form
>included in the expansion of a macro.  I think this would have a closer
>analogy to #,; in fact you just write , in your macro's backquote where
>you would have written #, when using the reader macro.  The above
>example would be written as follows:
>
>    (defmacro call-method (spec &rest args &environment env)
>      `(funcall (quote ,(make-load-time-eval
>			  `(load-time-look-up-method ',spec)
>			  env))
>		,@args))
>
>This is more verbose than the special-form way, but it may be clearer
>what's going on, since there aren't any special forms.  The environment
>is passed to make-load-time-eval because I don't see how else it is
>supposed to know whether the form resulting from the macro expansion is
>going to be compiled into a file or evaluated right away.  I'm not sure
>we really want to adopt the make-load-time-eval approach, but I think
>it may be worth discussing.

This would also be acceptable, though, as Dave noted, MAKE-LOAD-TIME-EVAL
would require some way of determining whether the form resulting from
the macro expansion will be compiled or evaluated right away. Since
environments are underspecified in CLtL, this information might not
be obtainable from the environment (though it probably would from special
variables or flags associated with the compiler, in an implementation
dependent way).


>I also happen not to believe the stated usefulness of this for object
>oriented programming, but that's irrelevant except that I might want to
>suggest removing that from the proposal.  Certainly we all know that this
>type of feature is highly useful.

The usefulness comes primarily in constructing optimizations removing
method lookup. There are a number of areas where this might be handy,
including direct invocation of less specific methods, declaration of
identifer names and generic function names so particular methods
rather than their generic functions are invoked, etc. To an extent,
these can be viewed as implementation and machine specific (conventional
architecture implementations would probably benefit more), or, more
precisely, implementation and machine optional. However, as pointed
out, the type of feature which the proposal was trying to get at
could be more generally useful.


>In conclusion, I support the general idea but cannot support the particular
>wording of the current version of the proposal.  When I started writing
>this message, I was going to include a complete revision of the proposal,
>but I have run out of energy.

If general feeling seems to indicate, I can reword the proposal along
the lines of MAKE-LOAD-TIME-EVAL, or clean up the existing proposal.
One additional problem with the existing proposal is the need and
desire to avoid introducing additional special forms into Common Lisp.

Any other comments?
			jak