[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue CONSTANT-COMPILABLE-TYPES, version 7
- To: email@example.com, firstname.lastname@example.org
- Subject: Re: Issue CONSTANT-COMPILABLE-TYPES, version 7
- From: cperdue@Sun.COM (Cris Perdue)
- Date: Sat, 11 Mar 89 17:18:44 PST
> I guess I pretty strongly object to leaving functions out of the list
> of constants that can appear in compiled code. The part that's
> disturbing is that such non-Lispy things like arrays, hashtables, and
> pathnames get better treatment than functions, the most Lispy part of
> Common Lisp. I wonder how many implementations will be forced to come
> within an inch of the required functionality to implement a first-rate
Thanks for the note. I feel a good deal the way you do about the
importance of functions.
> The specification of the subset of functions that are acceptable as
> compiled constants cannot be tested for within Common Lisp itself.
Sigh. Did we remove compiled-function-p from the language? My
thought was that functions not closing over any variables and
for which this test would return NIL would have to be accepted
as compiled constants.
> I suggest we ask implementors (Lucid included) to bite the bullet and
> handle this case correctly. Won't our grandchildren appreciate us
> treating Common Lisp like Lisp and not like PASCAL?
There are technical issues regarding closures, and since you are
interested, I solicit your opinion:
There is of course a set of lexical variables and their state
associated with each closure. Most objects resulting from
file-compilation and loading may be made immutable (as specified
in the proposal). This would seem inappropriate for the closed-over
variables and the objects referred to by those variables.
Is this your view also?
There is also an issue concerning how carefully to preserve the
identities of variables closed over by more than one compiled and
reloaded closure. Finally (I hope this is all) there are issues
concerning how carefully to preserve the identities ("EQ-ness") of
objects referred to by closed-over variables. Uninterned symbols
presented similar issues, and careful preservation of identity turned
out to be desired there.
Basically I have been reluctant to take on the picky technical
issues here, but I hope someone else will have more energy on this
than I have. A cleanup proposal that would amend/augment
CONSTANT-COMPILABLE-TYPES:SPECIFY would be welcome.