Issue: PROCLAIM-SCOPE (Version 1)

[Jon L White <jonl@lucid.com>]

re: Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE):

      Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
      the scope of a proclamation.

      (PROCLAIM proclamation :LOCALLY T)
	In a file, this would put the PROCLAMATION into effect for the entire
	rest of time during which the file was being loaded (including
	recursive loads).

	Interactively, it would be the same as :LOCALLY NIL.

      (PROCLAIM proclamation :LOCALLY NIL)
	In a file or interactively, this would put the PROCLAMATION into
	effect permanently. (The declaration would not be retracted when the
	file was done loading.)


Although you've called this a "scoping" issue, you've really made it an
"extent" issue. (See CLtL Chapter 3).  The phraseology "... would put the 
PROCLAMATION into effect for the entire rest of time during which the file 
was being loaded ..." bears this out.


Lucid Common Lisp has a function called FILE-PROCLAIM, which has essentially
the same semantics as your proposal:  It "retracts" all proclamations
made during the loading/compilation of the file.  But we decided not to
recommend its use, precisely because we thought most users would confuse 
the issue of dynamic extent with local scoping.

In fact, one of the issues in my "private" list of things that we at Lucid
are concerned about, but which have not had a satisfactory submissions to 
the cleanup committee yet, is just the matter of a "Lexical Proclaim".  In 
the hardcopy sheet I handed out to many committee members, at the Palo Alto
meeting in March of this year, there should have been the paragraph:

 (5) Add a lexical "pervasive" declaration special form; e.g, 
	   (locally (pervasive-declare (special foo))
	     ...)
     has syntax like 'declare, but acts more like proclaim; it pertains only
     to the lexical scope indicated -- its action is not dynamically scoped. 
     In particular, it differs from 'declare' in that interior binding forms 
     "inherit" the declaration, rather than forming a "wall" against it.


This is the functionality that I would support, even though wrapping
a 'pervasive-declare' around a 'defun' has implementational consequences
similar to wrapping a non-null 'let' [i.e., there may be a non-null
lexical environment].



-- JonL --