I have a GCL lisp newbie question whose answer
I can't remember, and can't find it on google.
The command I'm looking for is how to exit the debugger and
return to the top level eval loop. I've tried using :HELP, quit,
resume, return, abort. It's driving me out of my mind., can anyone
point me in the right direction?
Any help appreciated
- Tom Z
On Oct 13, 9:06 pm, ······@gmail.com wrote:
> I have a GCL lisp newbie question whose answer
> I can't remember, and can't find it on google.
>
> The command I'm looking for is how to exit the debugger and
> return to the top level eval loop. I've tried using :HELP, quit,
> resume, return, abort. It's driving me out of my mind., can anyone
> point me in the right direction?
> Any help appreciated
Try
:q
Gene wrote:
> Try
>
> :q
This ma be a good answer for this particular implementation, but
Common Lisp doesn't have "commands." Portably in ANSI CL you can
investigate the available restarts with the function (compute-restarts)
and invoke a restart using invoke-restarts. Something like
(invoke-restart (car (compute-restarts)))
is a good guess at how to return to the initial top level. But
unfortunately this isn't portable.
The condition system in ANSI CL is quite elegant, and I'm one
of the people who long ago voted its inclusion into the standard
language, but I also believe that it does not sufficiently
specify how the condition system (restarts especially!) integrates
into the standard execution environment.
From: Kent M Pitman
Subject: Re: How do I get out of the debugger in gcl (gnu common lisp)?
Date:
Message-ID: <ufy0dr6kg.fsf@nhplace.com>
"Steven M. Haflich" <···@alum.mit.edu> writes:
> Something like
>
> (invoke-restart (car (compute-restarts)))
>
> is a good guess at how to return to the initial top level.
To the initial top-level? Most restarts are likely to be pushed onto
the front, so that, if anything, is going to get you to to the
innermost toplevel.
One might think (invoke-restart (car (last (compute-restarts)))) would
then do it, but many things like service threads for servers may have
no such thing, and if you're debugging one of those, you can accidentally
blow away your service therad if the last restart was "Abort this thread."
It's pretty dangerous to be blindly calling restarts without knowing what
they are.
> But unfortunately this isn't portable.
That's for sure.
In LispWorks, this gets caught by the debugger, as does (abort) or
(invoke-restart (find-restart 'abort)). I suspect the reason is that
they are evaluating debugger expressions with a
(with-simple-restart (abort "Return to debugger level blah") (eval ...))
kind of thing out of fear there will be something in the debugger expression
that trise to abort (which certainly can happen).
I believe there are some simple and more reliable ways around this
that I'm pretty sure ARE portable, but they involve a bit of thinking
outside the present frame of reference, and an explanation of them doesn't
fit in the margin of this post, so I'll leave them as exercise to the
reader. ;) I've made some private notes on the matter for possible
discussion at another time.
> The condition system in ANSI CL is quite elegant, and I'm one
> of the people who long ago voted its inclusion into the standard
> language, but I also believe that it does not sufficiently
> specify how the condition system (restarts especially!) integrates
> into the standard execution environment.
Well, as to OP's problem, that's really abot the debugger, not restarts
in general, and that was mostly left explicitly to the implementations.
Your residual point, about restarts, is well-taken even if not, IMO,
the primary problem the OP is up against. I definitely agree more
detailing of restarts is a principal need of the condition system
moving forward. As you surely know, having been there at the time, it
wasn't an oversight that we didn't do it--budget and concerns raised by
specific vendors about impact on them were the constraint.
Some historical notes follow here. You were involved in the process,
Steve, and probably know musch of this, but others may not be able to
readily see it since it's not all written down; hopefully you and
other participants reading on chime in if you see something that's
wrong or that you had a different perspective about.
The committee had little budgeted time for managing those details, nor
did the vendors have substantial agreement. It was recognized as a
large-scale task that we could only commit to a small amount of, and the
line that was drawn was to try to get argument checking specified (but
not to worry about correcting those problems other than to say that
use-value and store-value might be available to help), and to specify
a few conditions about files (but again not to specify the rich language
that the LispM was offering for proceeding errors).
The deadlock came from the issue that some errors were local file
system errors and some were network file system errors, but a small
number of vendors didn't want to admit multiple inheritance. My
recollection was that Gold Hill Common Lisp, which targeted very small
processors, was the key player in pushing for conservatism here, but
there may have been others. (It may have been efficiency, or distrust
that the community would catch on, or lack of love for the
paradigm--since there as all of that in the air from a few people, but
I recall the predominant cited reason was image size: they wanted to
be able to deliver applications that didn't have multiple inheritance
support in them, and they were sure all applications would signal
errors.)
In fairness to the Gold Hill guys, who had VERY different concerns
from other vendors, there really were (and still are) people for whom
image size was central. Rather than make some blanket statement that
they were just "holding the community back", I would note that, in my
opinion, they were principally responsible for the push to make lists
starting with LAMBDA not be functions (an incompatible but much-needed
change between CLTL and ANSI CL) and for generally sorting out the
whole business of trying to keep the footprint of EVAL/COMPILE out of
certain primitive coercion operations, in order to keep the presence
of a coercion in a piece of code from forcing the entire
compiler/evaluator to be dumped into an image. I'm not sure this was
all done perfectly even in the final form, but it was a lot better in
ANSI CL than in CLTL. So there are times when a disparate community
is not a bad thing, and where the need to compromise with parties that
have very different needs can make things stronger.
But in this case, about conditions, the internal 'agreement' of the
designers not to put multiple inheritance into the final design of
conditions (even though it would be there for user-written standard
classes using DEFCLASS, so it might not be apparent that this was a
requirement), meant we couldn't say there were file errors that might
also be network errors. And that meant we couldn't say much, and we
backed off of using the Symbolics model as the standard model even
though it had 5 years of commercially deployed experience in the field
with a working model where people did useful error handling and
restarting. This is the thing that happens with consensus
processes--sometimes it moves stragglers ahead, but sometimes it
stalls the ones who want to move ahead.
It's why I think it's better to just let people move at their own
pace--the ones who are using older stuff will either be shown by the
market to have a healthy interest in stability or an unhealthy
interest in nostalgia; the ones who are using the newer stuff will
either be shown to be insightful or foolhardy. But in all cases, the
failures of one point of view do not imply the failure of others. A
consensus process puts everyone together in a sink-or-swim situation,
which has some good effects and many risks.
Fixing specs for ways out of these problems should use a layered or
modular standards module, creating a package of elements and allowing
vendors to voluntarily comply. It's messy--it means not all vendors agree.
But at least it means you can move forward apace. This was successfully
done with Gray Streams and Simple Streams (both of which have had their
champions, and none of which has been disruptive). It's also been done
with the MOP.
I think the MOP [not as a spec, but as a design process] offers a good
model of the issues that arose. It was not something we didn't think
of at the time--it was something we did think of but that the
committee was not ready for, and for specific reasons: It appears to
specify the details of how the vendors DID this [emphasis on past
tense], but since you can't every really specify what someone DID in
the past from the present unless you know they did it that way, what's
really going on is you're telling people what they must do in the
future to come into line. In the case of the MOP, being a voluntary
compliance issue, most existing vendors have come into line and do
comply, but a few haven't done it at all and are not burdened by
anything other than non-support of that feature. Users can then
decide what's right. If the MOP had been done in a way that required
compliance, the Symbolics Lisp Machine, for example, would likely have
decided it could not support CL, because so much work was needed to do
it. In the condition system, the situation was exactly the
reverse--the Symbolics system had a very elaborated notion of
conditions and restarts, but my sense was that other vendors were
nervous that having to change a huge amount in order to come into line
with that, and they had little "current practice" of their own to
guide an alternate choice.
And, of course, at this point vendors each have communities that are
used to what they're doing but who are not all doing the same thing.
The above is all just my personal opinion, and others might reasonably