[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

What is this RESTART kludge?



First a simple question.  What is the subform in a RESTART form good for?
According to the interpreter, a RESTART form contains a subform that gets
evaluated before the restart happens.  Its value is carefully thrown back to
the matching BLOCK, and is then ignored.  My current best theory is that it is
simply a spaz on GLS's part, perhaps because he simply copied the code for
RETURN.  For the rest of this message I am going to assume that this is the
case and that this subform isn't really there.

Also in the recent evaluators there are two RESTART special forms.  RESTART and
RESTART-FROM.  Where RESTART could be a macro expanding as: (RESTART) ==>
(RESTART-FROM NIL).

According to Moon's notes, the decision to have this RESTART form was made at
the last meeting, and there it was agreed that the syntax would be:  
(RESTART [block-name]) presumably with the block-name defaulting to NIL.  At
the very least I would prefer this to having the additional RETURN-FROM form.
[Although perhaps this is evidence that GLS really intends there to be a
gratuitious subform in a RESTART?]

A somewhat larger complaint I have is that having (RESTART) mean to restart a
block named NIL a really BAD idea.  Blocks named NIL are frequently produced by
macros (like LOOP, DOTIMES, etc.) that would do something totally bogus if you
were to try to restart them.  A block named NIL means an iteration, and the
fact that you can RETURN from it is a convenience because you frequently want
to exit a loop in an arbitrary manner, but restarting an iteration is not
something that needs to be made convenient.  Also I really dread the thought of
re-writing all the macros in the world that use DO or PROG to allow for some
loser restarting them.  If we must have RESTART, then it should ALWAYS take a
block name.

Finally, I really don't understand why we need to clutter up the language with
this RESTART thing in the first place.  Why should I prefer
(BLOCK FOO ... (RESTART FOO) ...) over (TAGBODY FOO ... (GO FOO) ...)?  I have
this sneaking suspicion that it has something to do with gotophobia, which is
silly.

It seems that we have nicely split the actions of PROG into three simpler
special forms, and then we are repeating the mistake we made in overloading
PROG by adding a new kludge to BLOCK.  Wouldn't the following do just as well
as a private macro for people who like their code to look this way?

(defmacro restartable (name &body body) `(tagbody ,name (progn ,@body)))

(defmacro restart (name) `(go ,name))


Alternatives:  [in order of decreasing desirability in my opinion]

A)  Flush it.  [Yeah!]

B)  Have a fifth distinct environment containing restart block names, and a new
special form to introduce it (similar to the RESTARTABLE macro defined above).
In this case it wouldn't be totally unreasonable to have (RESTART) mean
(RESTART NIL), since it wouldn't interact with BLOCKs at all.  [In other words,
if we have to have it, lets do it right.]

C)  Install the RESTART and RESTARTABLE macros I defined above.  [If we can't
do it right, lets build knowledge of it into as few places as possible.]

D)  Keep the restart block namespace the same as the return block namespace,
but specify that a block name must ALWAYS be given to RESTART.  [At least let's
not have it be a shaft.]

E)  Keep things as they are now except perhaps for clarifying the bit about the
random subform and the need for both RESTART and RESTART-FROM.  [The very lesat
we can do.]