[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
- To: Dan L. Pierson <email@example.com>
- Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Thu, 16 Mar 89 12:05:34 MST
- Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, email@example.com
- In-reply-to: Dan L. Pierson <firstname.lastname@example.org>, Thu, 16 Mar 89 13:42:07 EST
> Date: Thu, 16 Mar 89 13:42:07 EST
> From: Dan L. Pierson <email@example.com>
> One of Kent's points in earlier discussion was that it should (read
> MUST) be safe to blindly apply to COMPILE to any symbol with a
> function definition. I thought there was general agreement on this.
> If the lastest draft contradicts this then it needs to be fixed.
The current wording (from proposal COMPILE-ARGUMENT-PROBLEMS) says
"it is an error". My recollection is that we agreed to an editorial
change to "the consequences are unspecified", assuming the error
terminology ever gets sorted out.
Now that I think about the interaction between the two proposals, it
does seem like there is a problem -- we can't require a
COMPILED-FUNCTION to be returned and leave the behavior unspecified at
the same time. I think we need to do one of two things:
(1) Require COMPILE to signal an error if it can't return a
(2) Say that COMPILE is required to return a COMPILED-FUNCTION only
in the situations that are not unspecified.
Any further thoughts on this? My personal leanings are towards
signalling an error.