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