[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
- To: "email@example.com"@Multimax.encore.com (Sandra J Loosemore)
- Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
- From: Dan L. Pierson <firstname.lastname@example.org>
- Date: Thu, 16 Mar 89 14:18:10 EST
- Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, email@example.com
- In-reply-to: Your message of Thu, 16 Mar 89 12:05:34 -0700. <8903161905.AA05839@defun.utah.edu>
From: firstname.lastname@example.org (Sandra J Loosemore)
Date: Thu, 16 Mar 89 12:05:34 MST
> 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.
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. Specifically, it should be legal and safe to
attempt to speed up my current program(s) by doing:
(DO-SYMBOLS (SYM <my-package>)
(WHEN (FBOUNDP SYM) (COMPILE SYM)))