Issue: COMPILE-ENVIRONMENT-CONSISTENCY (Version 3)

[gz@spt.entity.com (Gail Zacharias)]

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Wed, 25 Jan 89 09:16:50 MST
   Item 2c (block compilation) has been more controversial -- KCL does
   this, but many people seem to think that this should not be the
   default behavior of the compiler.  My plan for voting on this issue at
   the last meeting was to first ask for a vote on an amendment to remove
   this particular item, but it never got that far.  I suppose that if
   nobody speaks up for it in the meantime, we could just go ahead and
   remove it from the next version. 

Well, I'm speaking up for it.  This item has nothing to do with whether
anybody does it by default, and a lot to do with whether a block-compilation
option can be made available to *users* of Common Lisp programs (you know,
those people twice removed from implementors that we're doing all this for).
The question is whether an end user can take a Common Lisp program whose
internals he's not familiar with, block-compile it, and be guaranteed that it
will continue to function correctly.  This item says that yes, a correct CL
program must explicitly indicate what functions in the source it will redefine
at runtime.  I don't think this places such a great burden on the programmer.
Without this provision, only somebody intimately familiar with a program could
know whether it can be safely block-compiled, making block-compilation useless
in the context of portable CL programs.

This thing about "block compilation shouldn't be the default" seems to come up
every time this item is discussed.  That's an environment question and is not
addressed by the proposal.  The proposal simply says that block compilation
should be legal.  Maybe some explanation of this can be placed in somewhere in
the proposal to avoid repeating this discussion at the next meeting...