issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

I've done a total rewrite on this issue.  There are now three
proposals, which I think cover the range of possibilities.  I think
that doing nothing with this issue would be the equivalent of
approving proposal NO.

I was going to send this out to X3J13 with our other proposals on
Monday.  I realize that doesn't give you folks enough time to review
this properly, so I've marked it as being a draft.  We can bring a
revised version to the meeting or decide not to bring it up for a
vote, if necessary.


Issue:		PROCLAIM-ETC-IN-COMPILE-FILE
References:	CLtL p. 182 [package functions],
		  p. 156 [PROCLAIM], p. 439 [COMPILE-FILE];
                Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
		Issue IN-PACKAGE-FUNCTIONALITY
		Issue EVAL-WHEN-NON-TOP-LEVEL
		Issue DEFINING-MACROS-NON-TOP-LEVEL
Category:	CLARIFICATION, CHANGE, ADDITION
Edit History:   15 Sep 88, V1 by David Gray
                23 Sep 88, V2 by Sandra Loosemore (summarize discussion)
		11 Mar 89, V3 by Sandra Loosemore (rewrite)
Status:		**DRAFT**
 

Problem Description:

  Should the compiler treat top-level calls to PROCLAIM specially?

  Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
  to the following package functions as though they were wrapped in an
  (EVAL-WHEN (COMPILE LOAD EVAL) ...):

    EXPORT  IMPORT  IN-PACKAGE  MAKE-PACKAGE SHADOW
    SHADOWING-IMPORT  UNEXPORT  UNUSE-PACKAGE  USE-PACKAGE

  CLtL is silent on whether top-level calls to PROCLAIM should also be
  evaluated at compile-time, which presumably means they shouldn't be.
  However, some implementations do evaluate PROCLAIM at compile-time.

  In the model of how COMPILE-FILE works that is presented in issues
  EVAL-WHEN-NON-TOP-LEVEL and DEFINING-MACROS-NON-TOP-LEVEL, the special
  form EVAL-WHEN is the only thing that can cause compile-time evaluation
  to occur.  The compile-time side-effects of macros such as DEFMACRO
  and DEFPACKAGE are explained by having them include EVAL-WHEN in their
  expansions.  Any functions that are treated specially, however, must
  be included as special cases in the compiler.

  Proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO would remove the
  requirement that the package functions be treated specially.  Do we
  wish to make an exception to the model for PROCLAIM?


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) ...).

  Rationale:

    Proclamations affect compilation semantics and should be made 
    available to the compiler.


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.

  Rationale:

    This makes the semantics of COMPILE-FILE more uniform and easier 
    to understand.  In particular, if we remove the magic compile-time
    behavior of the package functions, it seems silly to add another
    exception for PROCLAIM.


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.

  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,
  or use the macro DEFPROCLAIM.

  Rationale:

    The macro makes the proclamations available to the compiler in such
    a way that does not require any special exceptions to be made in
    the model of how COMPILE-FILE works.

Current Practice:

  The TI explorer apparently implements proposal YES, except that
  (EVAL-WHEN (LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything.
  The Symbolics compiler has special top-level handling for PROCLAIM,
  although the details are not clear.

  Lucid does not evaluate calls to PROCLAIM at compile-time.

Cost to implementors:

  Since implementations are already required to have a mechanism for
  compile-time handling of the package functions, it would probably
  only require minor adjustments to add handling for PROCLAIM.

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.

  Under any of these proposals, some users would probably have to
  make minor changes to their code.
  
Benefits:

  Users will know what to expect when they use PROCLAIM.
  
Costs of Non-Adoption: 

  Users will not know what to expect when they use PROCLAIM.

Aesthetics:

  At least two people consider requiring magic behavior for certain
  top-level function calls to be "semantically bletcherous".  Removing
  all special cases for functions that are implicitly evaluated at
  compile-time would simplify the model of how COMPILE-FILE works.

  Programs look cleaner if EVAL-WHEN is only needed for unusual cases
  instead of being required for the normal cases.
 
Discussion:

  The first version of this writeup also included REQUIRE with PROCLAIM,
  but we have now voted to remove REQUIRE from the language entirely.
  It also specified that OPTIMIZE proclamations should only have a local
  effect within the file being compiled.  This was removed for 
  consistency with other compile-time side-effects (such as those from
  DEFMACRO), where their persistence is explicitly left unspecified.

  Loosemore favors proposal NO, but wouldn't oppose proposal NEW-MACRO.
-------