[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: DLW@SCRC-STONY-BROOK.ARPA
- Subject: TAGBODY
- From: Alan Bawden <ALAN@MIT-MC.ARPA>
- Date: Wed, 16 Oct 85 14:56:42 EDT
- Cc: common-lisp@SU-AI.ARPA
Date: Wed, 16 Oct 85 13:22 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
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 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:
(if (= x 1) (go 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.