[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue CONSTANT-FUNCTION-COMPILATION Writeup

Forum:		Compiler

Issue: CONSTANT-FUNCTION-COMPILATION

References: Issue CONSTANT-COMPILABLE-TYPES

Category: CLARIFICATION

Edit History: V1, 22 Mar 1989, Sandra Loosemore (split from issue

CONSTANT-COMPILABLE-TYPES)

Status: **DRAFT**

Problem Description:

Can objects of type FUNCTION (or some subset of FUNCTIONs) appear as

quoted or self-evaluating constants in compiled code?

There are two questions that must be answered:

- How does one test whether a particular function is a member of the

subset of functions that are dumpable?

- For those functions that are dumpable, how do COMPILE-FILE and LOAD

arrange for an "equivalent" copy of the function in the source code to

be created in the compiled code?

This writeup uses terminology from issue CONSTANT-COMPILABLE-TYPES:

"source code", "compiled code", and "similar as constants".

Proposal CONSTANT-FUNCTION-COMPILATION:NO:

Objects of type FUNCTION are not supported in compiled constants.

Rationale:

Nobody has been able to come up with a well-defined specification of

how the compiler and loader would be required to reconstruct

function constants that would work for all functions.

Nobody has been able to come up with a well-defined specification of

some subset of functions that could be dumped.

Current Practice:

Coral can dump compiled functions, but not foreign functions.

The TI Explorer cannot dump closures (either compiled or evaluated),

but can dump non-closure compiled functions.

Symbolics Genera can't dump closures either.

Kyoto Common Lisp can't dump any functions.

Cost to implementors:

None. Implementations that can dump (some subset of) functions may

continue to do so, since issue CONSTANT-COMPILABLE-TYPES permits

implementations to extend the notion of "similar as constants".

Cost to users:

None. Programs that depend on being able to dump functions are

already nonportable, since not all implementations can dump all

functions and there is no portable way to construct or test for

functions that are dumpable in those implementations.

Benefits:

Users will know what to (or what not to) expect when using functions

in compiled constants.

Discussion:

This issue was split from issue CONSTANT-COMPILABLE-TYPES because it

appeared to be controversial enough to merit separate discussion.

Cris Perdue originally suggested:

Only function constants that are not compiled-functions and do not

close over any (lexical) variables are supported in compiled

constants.

Two such functions are similar as constants if their

SOURCE-LAMBDA-EXPRESSIONs are similar as constants.

Dick Gabriel responded:

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

CLOS?

The specification of the subset of functions that are acceptable as

compiled constants cannot be tested for within Common Lisp itself.

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?

If we were to specify that all functions could appear as constants, we

would also need to clarify whether the closed-over variable bindings

become immutable, and also deal with whether bindings that are closed

over more than one function retain their uniqueness. Also, the cost

to implementors to add support for dumping non-interpreted functions

may be quite high.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.