[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
- To: "firstname.lastname@example.org"@multimax.encore.com (Sandra J Loosemore)
- Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
- From: Dan L. Pierson <email@example.com>
- Date: Thu, 16 Mar 89 15:21:22 EST
- Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, firstname.lastname@example.org
- In-reply-to: Your message of Thu, 16 Mar 89 13:09:11 -0700. <8903162009.AA05971@defun.utah.edu>
From: email@example.com (Sandra J Loosemore)
Date: Thu, 16 Mar 89 13:09:11 MST
> Date: Thu, 16 Mar 89 14:18:10 EST
> From: Dan L. Pierson <firstname.lastname@example.org>
> What I (and believe Kent) want is a guarantee that it won't signal an
> error; if nothing else works COMPILE will simply apply #'IDENTITY to
> the symbol's function.
If this is the position people really want to adopt, I think we ought
to flush the COMPILED-FUNCTION type. I can't imagine it would be
very useful in declarations if we always allow COMPILE to be a no-op
and never require it to return a COMPILED-FUNCTION.
While I would expect that a COMPILE which resulted in IDENTITY would
not necessarily make the function a COMPILED-FUNCTION, I have absolutely no
objections to flushing the type.
I still think that the minimum requirements for compilation specified in
the proposal should apply to COMPILE-FILE, regardless of what happens
to COMPILE and COMPILED-FUNCTION.
I agree. I would also accept a requirement that COMPILE could cause a
function to become a COMPILED-FUNCTION iff it met the minimum
requirements in the proposal. Note this could still mean, for a
function in which a prepass caused no changes, that IDENTITY could
cause the function to become a COMPILED-FUNCTION. While this may
sound a bit absurd it's consistent with the position we seem to be
adopting that, COMPILE is "macroexpand-completely" in an