#

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

Copyright 1996-2001, Xanalys Inc. All rights reserved.