[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue CONSTANT-FUNCTION-COMPILATION
- To: cperdue@Sun.COM (Cris Perdue)
- Subject: Re: issue CONSTANT-FUNCTION-COMPILATION
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Fri, 17 Mar 89 12:00:17 MST
- Cc: email@example.com, firstname.lastname@example.org, email@example.com
- In-reply-to: cperdue@Sun.COM (Cris Perdue), Fri, 17 Mar 89 10:47:53 PST
> Date: Fri, 17 Mar 89 10:47:53 PST
> From: cperdue@Sun.COM (Cris Perdue)
> > except that
> > FUNCTION-LAMBDA-EXPRESSION is always permitted to return NIL if it
> > can't figure out what the original source code looked like.
> So both must be non-NIL.
> > My
> > feeling is that this definition of "similar as constants" is
> > unacceptable because of this.
> Yes, please fix.
Let me get this straight. In addition to the requirement that the
function not be compiled and not be closed over any variables, you would
like to add an additional requirement that FUNCTION-LAMBDA-EXPRESSION
for that function not return NIL?
There is still a problem with the informal nature of your first two
requirements. Could we use the second value returned from
FUNCTION-LAMBDA-EXPRESSION for testing the second requirement?
If we retain the COMPILED-FUNCTION type, the problem with
detecting that a function is compiled is taken care of, but is there
any reason why we couldn't dispense with this? If you have the lambda
expression available and that is how "similarity as a constant" is
defined, it shouldn't matter whether the function is compiled or not.
Aside from the problems of specification, I am still wondering why,
since there is no portable way to construct a function which is
guaranteed to meet these requirements, we should bother to specify a
portable behavior for what happens when they are satisfied.