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 "