[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3
- To: email@example.com (Sandra J Loosemore)
- Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Mon, 13 Mar 89 18:34:59 CST
- Cc: firstname.lastname@example.org
- In-reply-to: Msg of Sat, 11 Mar 89 13:41:24 MST from email@example.com (Sandra J Loosemore)
- Sender: GRAY@Kelvin.csc.ti.com
> Proposal PROCLAIM-ETC-IN-COMPILE-FILE:YES:
> Require COMPILE-FILE to treat top-level calls to PROCLAIM as if they
> were wrapped in an (EVAL-WHEN (COMPILE LOAD EVAL) ...).
This is my preference.
> Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NO:
> Clarify that calls to PROCLAIM should be treated the same as any
> other function call. Users should wrap an explicit EVAL-WHEN around
> top-level calls to PROCLAIM if they want them to affect compilation.
This means that the EVAL-WHEN would be needed on nearly every use of
PROCLAIM, which goes against the model that EVAL-WHEN is only needed for
exceptional situations. (Page 69 of CLtL says about EVAL-WHEN that "Its
uses are relatively esoteric.")
> Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
> Add a new macro:
> DEFPROCLAIM &rest decl-specs [Macro]
> This macro PROCLAIMs the given <decl-specs>, which are not
> evaluated. If a call to this macro appears at top-level in a file
> being processed by the file compiler, the proclamations are also
> made at compile-time. As with other defining macros, it is
> unspecified whether or not the compile-time side-effects of a
> DEFPROCLAIM persist after the file has been compiled.
I don't like this name because the convention is that macros with names
beginning with DEF... are used to define things, with the name of the
thing being defined appearing as the first argument or as part of the
first argument. DEFPROCLAIM doesn't define anything. I think this
would also confuse users because it has the same syntax as DECLARE, but
the two can't be used interchangeably. It makes me wonder whether we
should just permit top-level DECLAREs, but then _it_ would need special
handling by the compiler since a macro definition would confuse the
semantics of local declarations, so you don't win.
> Cost to users:
> For proposal YES, users would have no way to suppress compile-time
> evaluation of a top-level call to PROCLAIM. Wrapping it in an
> (EVAL-WHEN (EVAL LOAD)...) wouldn't work under the model of how
> EVAL-WHEN works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.
How about (LET () (PROCLAIM ...)) ?