Issue: FLET-IMPLICIT-BLOCK (Version 6)

[Masinter.pa@Xerox.COM]

I think all I did was minor formatting changes (e.g., Defun => DEFUN,
Revision -> Version, SEF -> Fahlman, etc.) although it was a long time
ago today and I'm not 100% sure.

Status: Ready for release?

!
Issue:        FLET-IMPLICIT-BLOCK
Reference:    CLtL p. 113, 67
Category:     Omission. 
Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33
              Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12 
              Versions 4,5 by Fahlman 11-Apr-87
              Version 6 by Masinter  5-Jun-87


Problem Description:

Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE have an implicit block around their bodies like the body of a
DEFUN?  CLtL is silent on this point.  Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with DEFUN.

Test case:

(defun test ()
  (flet ((test (x) (if x (return-from test 4) 3)))
	(list (test nil) (test t))))

(test)

will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would
return 4 in an implementation that did not add an implicit block around
Flet.

Proposal: FLET-IMPLICIT-BLOCK:YES

Each function created by FLET and LABELS and each macro created by
DEFMACRO and MACROLET has an implicit block around the body.  The name
of this block is that same as the (lexical) name of the function or
macro.  Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE is surrounded by a block with the same name as the accessor or
type.

Current Practice:

Current practice is mixed.  Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.

Cost of adopting this change:

Some implementations will have to be modified.  This should be a
relatively easy modification.

Cost of not adopting the change:

If the issue is not clarified one way or another, continuing confusion
will result in portability problems.  Clarifying the issue in any other
way would also require modifications in some implementations.

Cost of converting existing code:

It is possible that some user code would break because it does a return
 from within a code body to an outer block that has the same as the
newly-required block.  Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect.  It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.

Discussion:

The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions.  The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.

Two alternatives to the proposal were considered and rejected:

The first would be to keep the implicit block in DEFUN, and to clearly
state that the other forms do not create implicit blocks.  This violates
the goal of consistency between lexical and global definitions, and it
seems to conflict with users' expectations.

The second alternative was to eliminate the implicit block from DEFUN
rather than adding such blocks to other forms.  There was some feeling
that specifying the implicit block in DEFUN was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself.  If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.

However, eliminating the implicit block in DEFUN would be a significant
incompatible change.  Some users find this implicit block to be a great
convenience for popping out of convoluted code, and some existing code
makes heavy use of this feature.  While such code could be repaired
automatically by searching for situations in which the user returns from
a function by name and by adding an appropriate explicit block to any
function containing such a forms, it would still require more more work
on existing user code than this proposal made above.

There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common in future Common Lisp
implementations.  The outcome of these discussions was general agreement
that a compiler could easily eliminate the implicit block in any case
where it is not actually used, and that the impact on tail-recursion
optimization in compiled code is therefore minimal.