[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Handling of #, (load-time-eval)
- To: CL-Compiler@SAIL.Stanford.EDU
- Subject: Handling of #, (load-time-eval)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 8 Jul 88 18:32 EDT
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
LOAD-TIME-CONSTANT form.]
- 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
(AREF *FORTRAN-MEMORY*
(+ #,(+ (GET-PROGRAM-OFFSET "FOO")
37) ;For example, program-relative offset of REAL A(10)
; known at compile time
(AREF *FORTRAN-MEMORY*
#,(+ (GET-PROGRAM-OFFSET "FOO")
47) ;eg, program-relative offset of B
3)))
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:
(AREF #,(SOME-ARRAY) n)
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.