Named PROG Feature

[GLS at SU-AI (Guy Steele)]

It has been suggested that a feature be introduced into LISP for
naming PROGs.  This would permit returns out of multiple levels
of PROG, allow more precise specification of non-local GOs,
and effectively provide the "lexical CATCH" notion.  Here I attempt
to gather together all the proposals for possible syntaxes for this
feature.  I would like to reach a prompt decision on this feature,
so speedy feedback would be appreciated.

The basic notion is that a PROG can be assigned a name by which
RETURN and GO forms can refer to it.  As with CATCH, there is the
issue of whether it should be permitted to compute the name.
(I am inclined to say "no", given that the feature may be intended
to be more static in nature than CATCH).

I believe that two suggestions have been put forward for the syntax
of named PROGs:
(1)	(PROG <name> ( <-vars-> ) ...)
(2)	(PROG ( <-vars-> ) <name> ...)
I happen to favor (1), just because the name is a little easier to see.
One feature of (2) is that the name looks like a tag, which is both an
advantage and a disadvantage.

Possible syntaxes for RETURN are:
(1)	(RETURN <name> <value>)
(2)	(RETURN <value> <name>)
where in each case the <name> can be elided, meaning the immediately
containing PROG, as usual.  These both have the disadvantage of
conflicting with existing LISPM multiple-value syntax.  A more
off-the-wall possibility is:
(3)	(RETURN <value1> ... <valuen> . <name>)
where <name> can be elided.  This has the useless elegance that
() means the immediately containing PROG, and so is somewhat similar
to CATCH.  It has the severe inelegance of introducing dot notation.
Another possibility is just introducing a new keyword for non-local
RETURNs:
(4)	(NLRETURN <name> <value1> ... <valuen>)

Similar choices exist for GO:
(1)	(GO <name> <tag>)
(2)	(GO <tag> <name>)
(3)	(GO <tag> . <name>)		[this hardly seems justified!]
(4)	(NLGO <name> <tag>)
While there is no problem with multiple-value returns, there is one
with computed GOs.  Even without the named PROG feature, I would
lean toward an incompatible change, and introduce a special
COMPUTED-GO primitive, which could have its own funny syntax as
desired and would solve the problem of having a tag in a variable
FOO and wanting to say (GO FOO) -- the usual contortion (GO (SYMEVAL 'FOO))
will have insurmountable interactions with local variables in NIL.

-------