TAGBODY

[Alan Bawden <ALAN@MIT-MC.ARPA>]

    Date: Wed, 16 Oct 85 13:22 EDT
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
    Subject: TAGBODY
    There was some recent discussion of TAGBODY among a few of us here, and
    I'd like to pass along the gist of it to the full Common-Lisp mailing
    list.

    ...  The problem is that TAGBODY is defined to always return NIL....
    So there's no elegant way to make your new special form return its
    useful value.  As far as we can tell, you are forced to GENSYM a block
    name and establish a block around the TAGBODY.  Since the whole idea of
    TAGBODY was to let you get at tags and go-to's without establishing a
    block, this seems somewhat inelegant.

As I recall it, the point was that TAGBODY let you have tags and go's
without establishing -unnamed- blocks (the kind that plain RETURN would
return from).  And I don't see any problem with gensyming up a tag myself.
Especially since I, at least, think of TAGBODY as something for macros to
expand into, rather than as something that appears directly in source code.

    Had TAGBODY been defined to return the value of its last form, this
    problem would be solved.  Anyone who wanted the current behavior could
    always just write (PROGN (TAGBODY ...) NIL).  It's easy to write the
    existing TAGBODY in terms of the alternative one; unfortunately, it's
    hard to write the alternative one in the current language.

The problem with defining TAGBODY to return the value of its last form is
that there isn't always a last form.  What is the value of:

  (tagbody
       (princ "dog")
       (if (= x 1) (go done))
       (princ "s")
     done)

After you all have finished arguing about whether this -particular- case
should return NIL, T, no values, or whatever, I'll opine that I liked the
original simpler definition much better.

    I consider this a good example of what can happen if you introduce a
    new, untested idea into a language standard.  This particular case is
    not the world's biggest problem, but I hope it illustrates how hard it
    is to design a language feature in your head, and I hope it makes
    everyone think twice before we standardize on more untested ideas.

Yes indeed, it does seem to be hard to understand the consequences of
anything in your head.