I said:
>Below is a short recursive fn I published earlier this year. It parses 
>and solves an algebraic string using the operators +, -, /, *, ^, and 
>parentheses. If you're interested in seeing how the recursion works, run 
>it in the debugger, putting equations of different complexity into the 
>string. Watch the debugger's fn-stack display grow and shrink as you step 
>through or run on slow. Can you find the test that calls a halt to the 
>process? Can you identify the limiting factor that ensures this will 
>never exceed stack space?
>
I have egg on my face, because feeding this simple test to my recursive 
fn WILL exceed the stack space:
"1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1"

I had thought that the 255-byte string limitation would be enough to keep 
it from overflowing, but it filled the stack in only 30 iterations on my 
machine--way less than the potential 127.

I admit I'm surprised that stack space is that limited. When I get the 
overflow warning, "Less than 19xx bytes left on the stack", the 
debugger's stack indicator still indicates over 240k. I'm not sure where 
that discrepancy comes from.

Furthermore, attempts to decrease stack usage by getting rid of string 
vars in the fn met with no success. It seems likely that FB's temp 
strings (created by manipulations of other strings) get left on the 
stack, too. So far, I don't see a way to make this work. (But you know 
me: I'll keep looking.)

 0"0
 =J= a  y
  "