Issue LEXICAL-CONSTRUCT-GLOBAL-DEFINITION Writeup

Issue:               LEXICAL-CONSTRUCT-GLOBAL-DEFINITION 

References:          PPRINT-EXIT-IF-LIST-EXHAUSTED

                     PPRINT-POP

                     LOOP-FINISH

		     CALL-METHOD

                     CALL-NEXT-METHOD

		     NEXT-METHOD-P

Related issues:      Issue LISP-SYMBOL-REDEFINITION

                     Issue PRETTY-PRINT-INTERFACE

                     Issue LOOP-FINISH-NOT-FINISHED

Category:            CLARIFICATION, CHANGE

Edit history:        V1, 05 May 90, Sandra Loosemore

                     V2, 29 May 90, Sandra Loosemore (forgot one)


Problem description:


The description of PPRINT-EXIT-IF-LIST-EXHAUSTED and PPRINT-POP

in issue PRETTY-PRINT-INTERFACE specifies that "an error message

is issued" if either of these constructs are used anywhere other

than syntactically nested within a call on PPRINT-LOGICAL-BLOCK.

It is not clear whether this means "an error is signalled" or

"a message is printed", or whether this situation must be

detected at compile time or at run time.


This is actually a more general problem, since there are other 

constructs in the language that have similar scoping requirements:  

notably LOOP-FINISH, CALL-METHOD, CALL-NEXT-METHOD, and NEXT-METHOD-P.  

The error behavior of all of these constructs when they are referenced

outside the lexical scope where their behavior is defined ought

to be made consistent, as should the matter of whether they

are permitted/required/not allowed to be globally FBOUNDP.  


This issue incorporates items #2 and #23 from Loosemore's list.


Proposal (LEXICAL-CONSTRUCT-GLOBAL-DEFINITION:UNDEFINED):


  This proposal affects the constructs PPRINT-EXIT-IF-LIST-EXHAUSTED, 

  PPRINT-POP, LOOP-FINISH, CALL-METHOD, CALL-NEXT-METHOD, and 

  NEXT-METHOD-P, which are referred to as "lexically-scoped operators".


  (1) Change the descriptions of lexically-scoped operators to

  state that any attempt to invoke the operator outside of the

  lexical scope where its behavior is defined has undefined

  consequences.


  (2) Clarify that it is unspecified whether function names that

  are defined by the standard as lexically-scoped operators have

  global function or macro definitions (i.e., are FBOUNDP).


  (3) Clarify that the restrictions on redefinition or shadowing

  of symbols in the COMMON-LISP package (originally stated in issue 

  LISP-SYMBOL-REDEFINITION) are the same for symbols that define 

  lexical operators as for symbols that are globally defined as

  operators.


Rationale:


  This gives maximum freedom to implementors and avoids having to

  deal with sticky issues about whether errors are detected at

  compile or run time, etc.


Current Practice:


  I suspect it is fairly common practice to define these operators

  using MACROLET (etc) and provide a global definition that

  signals an error if it is invoked.


Cost to Implementors:


  None.


Cost to Users:


  None.


Cost of non-adoption:


  Part of the language specification remains imprecise,

  inconsistent, and confusing.


Performance impact:


  None.


Benefits:


  The language specification is made more precise, consistent,

  and less confusing.


Esthetics:


  Treating all of these guys uniformly is better than having them

  all specify something slightly different with regard to their

  behavior.


Discussion:


The situation with the DECLARE special form is related but not

entirely analogous, so it has been left out of this proposal.

From a purely abstract point of view, DECLARE is not a special form 

at all but simply a syntactic marker like LAMBDA, and the only

reason for defining it as an operator is to facilitate diagnostics 

about misplaced declarations.