[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
The logic behind introducing TAGBODY into Common Lisp was to separate
out the pieces of what PROG does, so that these pieces would be
individually available to programmers, and to macro-writers in
particular. PROG was broken up into three components: one to handle the
variable binding, one to handle the creation of the block, and one to
handle the tags and go-to's. The intention was to let programmers build
new special forms that had some of the traits of PROG but not all of
them. So far, so good.
Now, suppose you want to write a special form that does handle tags and
go-to's, and returns a useful value, but does not establish a named
block. There appears to be no elegant way to do this. The problem is
that TAGBODY is defined to always return NIL. Unlike any other special
form in the language, TAGBODY neither sets up a block nor returns the
value of the last form in its body. 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.
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.
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.
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>