During the top level read-eval-print loop we have both an ABORT and a
TOPLEVEL restart bound around each iteration, and indeed CLHS does
recommend that there should always be an ABORT restart -- just like we
The TOPLEVEL, however, is quite redundant: selecting it is identical to
selecting the outermost ABORT.
Unless there is a specific reason beyond being able to type TOP in the
debugger to select it, I propose doing away with it -- for me at least it
was for a long time confusing, causing me to wonder what the difference
between it and the outermost abort was.
Admittedly, TOP in the debugger is quite handy, but that can be handled by
making it a debugger command if desired.
From: William Harold Newman <william.newman@ai...> - 2005-03-10 16:40:36
On Thu, Mar 10, 2005 at 05:34:27PM +0200, Nikodemus Siivola wrote:
> On Thu, 10 Mar 2005, William Harold Newman wrote:
> Having a catch tag 'top-level-loop instead of the restart would
> make implementing the command simple, and the invocation could
> be further encapsulated in function SB-EXT:RETURN-TO-TOP-LEVEL;
> best of both worlds sort of thing.
> (Just need to add the catch-tag around the initialization file and
> --eval option processing too.)
> How's that sound?
Fine with me. I have been convinced that getting rid of the prompt
clutter in the common one-level-deep case is a net improvement; I'm
not that picky about the implementation details.
William Harold Newman <william.newman@...>
Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph