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


Issue LOOP-NAMED-BLOCK-NIL Writeup

Status:       Proposal OVERRIDE (version 2) accepted 12/91

Issue: LOOP-NAMED-BLOCK-NIL

Reference: Draft 9.126

Category: CLARIFICATION

Edit History: Version 1, 22-Dec-91, Kim Barrett

Version 2, 26-Jan-92, Kim Barrett (clarification, per KMP)

Problem Description:

(Note: All section numbers are from Draft 9.126)

Regarding:

section 8.1.2.2, page 8-2, last paragraph in section

Expansion of the \macref{loop} macro produces an implicit block named \nil\

unless \loop{named} is supplied. Thus, \macref{return} and

\specref{return-from} can be used to return values from \macref{loop} or to

exit \macref{loop}.

section 8.1.2.6, End-Test Control, p8-15, first itemization

\itemitem{\bull} The \loop{until} construct executes any \loop{finally}

clause. Since \loop{thereis} uses the macro \macref{return} to terminate

iteration, any \loop{finally} clause that is supplied is not evaluated.

section 8.1.2.6, End-Test Control, p8-15, second itemization

\itemitem{\bull} The \loop{until} construct executes any \loop{finally}

clause. Since \loop{never} uses the macro \macref{return} to terminate

iteration, any \loop{finally} clause that is supplied is not evaluated.

In his review, Barmar noted "hmm..." in regard to this issue of not having a

NIL block get generated even when NAMED is used. He and KMP discussed it and

decided (based on examining the Lucid and Symbolics implementations) that the

intent was clear and they would let it go.

In processing other review comments of Barmar's, KMP noticed that these two

items refer specifically to RETURN (rather than RETURN-FROM) being generated.

This suggests one of the following two things:

(a) RETURN was not intended in the second two cases, and RETURN-FROM was

meant.

(b) RETURN was intended intended in the second two, and this exposes the fact

that the part about having no NIL block in the first case was wrong.

How shall we proceed in fixing this?

Proposal (LOOP-NAMED-BLOCK-NIL:OVERRIDE):

Clarify that if a NAMED clause appears in a LOOP form then no implicit NIL

block is established by the LOOP form. That is, confirm interpretation (a)

and reject interpretation (b) from the Problem Description.

Editorial Impact:

The two bulleted items mentioned in the problem description need to be changed

to refer to the special operator RETURN-FROM rather than the macro RETURN.

Rationale:

Gives the user greater control over the expansion of a LOOP form, permitting

its use in places where it might not be desirable if a NIL block were always

established.

Examples:

(block nil

(loop named foo

do (return 'success))

'failure)

-> SUCCESS

Current Practice:

Apple MCL 2.0b3 and Lucid 4.0 do not introduce an implicit NIL block if a

NAMED clause is present in the LOOP form.

Symbolics LOOP always introduces a NIL block, in addition to any block

established for a NAMED clause.

Discussion:

Barrett:

I think (a) (RETURN-FROM was meant, rather than RETURN) is preferable. The

main use I've found for explicitly named blocks is to avoid accidentally

shadowing the intended receiver of a return-from when writing a wrapper

macro. If LOOP might always introduce a NIL block then you can't safely

write such macros in terms of LOOP forms.

GSB:

I'm not sure how much help this is; I'll try to explain the history behind

the current Symbolics implementation.

My personal preference is for NAMED to use the named block instead of

(rather than in addition to) a block named NIL. Now, at the time I

implemented the ANSI loop (and extensions) at Symbolics, I was under the

impression that NAMED was not part of ANSI. Maybe it had been dyked from

the standard, maybe it was in the process of being removed (there was this

minimalist pressure at the time). JonL, you remember anything about this?

I was basically working from the first draft that differed greatly from the

prior Lucid documentation.

Now, a semantic divergence occurred several years ago between the "NIL" and

other "MIT" loop sources, and the Symbolics Zetalisp loop source, because

someone (Me) got confused about the semantics of Zetalisp's named PROG. In

particular, I translated (prog name varlist ...) into roughly

(block name (let varlist (tagbody ...))). This is not a correct

translation: Zetalisp named prog establishes that block name IN ADDITION TO

a block named NIL. Therefore when I did NAMED (as an extension to ANSI), I

made it compatible with the existing (lisp machine) one, against my own

preferences, because it was only an extension and the incompatibility is

fairly subtle.


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