From ...
From: Erik Naggum
Subject: Re: Modifiable parameters?
Date: 1997/02/13
Message-ID: <3064830257628640@naggum.no>#1/1
X-Deja-AN: 218504459
References: <5doasq$ul1@Masala.CC.UH.EDU> <5dthtk$5g1@Masala.CC.UH.EDU>
mail-copies-to: never
Organization: Naggum Software; +47 2295 0313; http://www.naggum.no
Newsgroups: comp.lang.lisp
* Carl L. Gay
| You could try setting max-lisp-eval-depth higher.
* cosc19z5@Bayou.UH.EDU
| I did that (to enable some appreciable amount of recursion). I believe
| the maximum is around 600, which while not bad isn't enough to make me
| use it in scenarios where I don't know how many recursions I'll get into
| (it would be nice if Emacs also did some tail recursion optimization).
I'm getting a bit annoyed by these continued references to deficiencies in
Emacs that are really just deficiencies in your ability or willingness to
read the Emacs Lisp manual. I have already answered the implied question
"can I make Emacs more friendly towards recursion, and if so how" in your
incessant and incorrect complaints that "Emacs doesn't allow recursion"
with references to `max-lisp-eval-depth' and `max-specpdl-size', but lots
of people out there will still believe your misguided complaints. _please_
be more willing to ask for help and less willing to complain.
you "believe" there is a small maximum. I _know_ there isn't. you hit the
600 limit because that's what `max-specpdl-size' is set to and you probably
had one let-binding in your recursive function. increase the value of this
variable to some obscenely large value and watch Emacs hit some hard limit
and die, instead. again, it is more friendly of Emacs to complain than to
crash, and it crashes because being able to respond when you're out of
stack space may not be very expensive, but handling the situation cleanly
usually is. to illustrate this point: watch what various Lisps do when
they exhaust their memory -- clean recovery is not usually an option.
Emacs has taken great pains to survive a "memory outage" when the user
creates too many or too large buffers, by allocating a "memory reserve"
that it uses when it suggests that you save all buffers and kill and
restart Emacs. something similar is not undoable with stack space, but is
much harder to make work right. unlimited recursion depth also allocates
system stack space that is not typically returned to the operating system
when the stack unwinds. this is a frequent cause of the very large Lisp
images that people complain about.
#\Erik
--
my other car is a cdr