[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.