[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Handling of #, (load-time-eval)

I'm just on my way out the door so don't have time to go into it in
detail right now, but I've been feeling guilty about not making my
position on this be heard. I'll try to write up justifications for
the following positions when I have a bit of time (maybe next week)
but just so you know...

 - I feel strongly that #, is a minimal level of functionality
   necessary in CL. It would be well to specify whether it is
   intended to work either inside of QUOTE or outside, but it must
   be there in some form.

 - I do not feel that there is anything strange or low-level about
   #, . It expresses an abstract concept which is very high-level
   and fundamentally important to certain kinds of programming.

 - I think a special form such as the LOAD-TIME-CONSTANT form I
   proposed on CL-Cleanup a while back would be an important addition.
   I have seen no technical justification for not just providing it.
   It looks to me like you guys are getting overly ambitious and trying
   to define #, in terms of a revised EVAL-WHEN. [EVAL-WHEN is not
   trivially fixable, but even it serves a purpose and should be left
   alone if no suitable improvement can be devised. In any case,
   no matter what you think of EVAL-WHEN, I would ask you to not let
   those feelings keep you from making a good #, and/or 

 - There are numerous important uses of #, and LOAD-TIME-CONSTANT.
   CLOS is one use. The Fortran-To-Lisp translator which I wrote
   as an undergrad was another. Anything that involves `linking'
   requires this.

 - It is not adequate to say that this can be handled
   by closures and/or special variables because the code modularity
   may be inappropriate for closures, and the naming of special
   variables (if not also the size of all those wasted symbols!)
   would be prohibitive. Consider, for example, that my Fortran-To-Lisp
   translator used a Maclisp SQUID expression (the #, analog for
   Maclisp) on -every- translated variable reference. That is,
   A(A+3) in Fortran program FOO translated to
         (+ #,(+ (GET-PROGRAM-OFFSET "FOO") 
	         37) ;For example, program-relative offset of REAL A(10)
		     ; known at compile time
		       47) ;eg, program-relative offset of B
   Surely you don't expect me to make a closure for every one of these
   values. Surely you don't expect me to give every one of these values
   a name via DEFCONSTANT. How would I do that? Even if I did, I'd need
   a ``Pratt Stack'' (ask a Maclisp implementor) since the macro would
   have to be generating prerequisite DEFCONSTANT definitions on the fly.

 - Even if I could use closure references, they compile too slowly in every
   implementation I know of. QUOTE is generally just one move. A closure
   reference invariably has to indirect through some environment pointer.

 - I definitely need the capability of creating this kind of constant
   without guaranteeing that it will not be modified. I just did a flavors
   implementation and having this object be write-protected or copied at
   will was enough to screw my ability to use this. I sent detailed mail
   to Common-lisp about this but will send more mail later to this list
   because it looks to me like people aren't seeing the importance of this.
   It comes down to the fact, though, that I needed to implement instance
   variables by:
   where the (SOME-ARRAY) might return an array that would need to be 
   ADJUST-ARRAY'd later without losing EQ-ness so that updates to the
   ADJUST-ARRAY'd version were seen by the array that (SOME-ARRAY) returned.

That's all I have time for right now. I hope this info is of use to you.