Issue COMPILER-MACRO-IMPLICIT-BLOCK
Issue: COMPILER-MACRO-IMPLICIT-BLOCK

Forum: Editorial

References: :(CLHS DEFINE-COMPILER-MACRO), Issue FLET-IMPLICIT-BLOCK

Category: CHANGE

Edit history: 2004-06-10, Version 1 by Nikodemus Siivola

Status: For CLiki consideration

Problem Description:
Current definition of :(CLHS DEFINE-COMPILER-MACRO) violates the rule of thumb observed by other named entities that take code bodies, that is mentioned in the Issue FLET-IMPLICIT-BLOCK writeup: "any named entity that takes a code body establishes an implicit block with the obvious name."

Proposal COMPILER-MACRO-IMPLICIT-BLOCK:YES
Specify that :(CLHS DEFINE-COMPILER-MACRO) establishes an implicit block with the name of the compiler-macro as the block name.

Test case:

Rationale:
The current behaviour violates expectations and complicates writing compiler-macros in some cases.

Current practice:
As defined in the standard, :(CLHS DEFINE-COMPILER-MACRO) does not establish an implicit block.

Cost to Implementors:
Small.

Cost to Users:
None. The altered definition would not affect behaviour of conforming code.

Cost of Non-Adoption:
The unintuitive behaviour violating expectations catered for by the rest of the language remains. Users writing complex compiler macros that would benefit from having a non-local exit via :(CLHS RETURN-FROM) must explicitly establish the block.

Benefits:
More uniform specification and easier to write compiler-macros in some cases.

Aesthetics:
Improved. Cleaner specification due to increased uniformity. Cleaner user code due to lack of explicit blocks in compiler-macros (though rare).

Discussion:
  • Bruno Haible says: Agreed, with a minor change: DEFINE-COMPILER-MACRO should establish an implicit block, like DEFUN does (using the notion of "function block name").