From: Nikodemus S. <nik...@ra...> - 2005-03-09 13:25:23
|
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 have. 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. Cheers, -- Nikodemus |
From: William H. N. <wil...@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 <wil...@ai...> Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |