CoCoA » CoCoA-5

Candidates for the name of the new fn:
SetMaxCallDepth
SetCallDepthLimit

It is probably best not to call it something like SetRecursionLimit because it simply counts depth of nested fn calls, and a single recursion level might entail more than a single nested call (I think).

PS edit to add other suggestions

John Abbott wrote:

Candidates for the name of the new fn:
SetMaxCallDepth
SetCallDepthLimit

I like SetCallDepthLimit

Should the capability to alter the max fn call depth be a function or a command?

Will it be possible to decrease the max call depth? Could this ever be useful?

If it's a function, what value should it return? The previous max depth?

If it's a command, what syntax should it have? C4 has a Set command for setting various system parameters; it is not present in C5.

Should changing the max call depth be allowed only at top level?
If it is permitted in other circumstances, what should happen if the max call depth is set to a value below the current call depth? (immediate error?)

JAA thinks: allowed only at top level (this can easily be enforced if we use a special command); max depth may be increased or decreased (no technical reason to forbid decreasing it).

Comment? Opinions? Ideas?

I have a first impl, but it SEGVs if I increase the stack size; don't know why.
The CoCoA-5 input is this: (initial stack size is set to 20)

Define SumFact(N) if N=0 then return 0; else return N+SumFact(N-1); EndIf; EndDefine;
SetStackSize(50); --> might cause the vector to reallocate
SumFact(21);

Giovanni can you give me a hand here?

I notice that the frames in the stack contain raw pointers to other frames; why?
These raw pointers are problematic if the std::vector reallocates; this is probably the cause of the SEGV, but it's not clear who's trying to follow these dangling pointers.

It's complicated; short answer: a frame needs to "point/reference" other frames for accessing non-local variables (e.g. in a lambda).
Now, using a raw pointer is (supposedly) more efficient than keeping an index, which has to be transformed into a pointer later (by adding the current begin of the stack with the index). Obviously, keeping a raw pointer means that frames cannot be moved around. It was an array, and not a vector, for a reason ;-)
I don't remember the details, so I'm not sure whether this is the only place where the code assumes that frames do not move. I suggest to revert your changes and raise the constant if needed (actually, you could probably dynamically allocate the array once, so you could use a command line option to set the limit, but the limit must be set once for all for each run of the interpreter)

I had suspected as much. Some guys wanted a stack size of about 250000, and asked for a command to increase stack size.

The command line option would surely be the simplest solution; I wonder if it would be enough -- I need to think about it (on the whole I don't much like command line options).

It still surprised me that I got a SEGV when the first command I executed was SetStackSize (so there should not have been any need to refer to non-local variables).

Here is a reason why I prefer a built-in fn for increasing max stack height over a command line option: a user discovers part way through a long session (with several costly computations) that one fn call fails because of insufficient stack space; with a command line option the user has to discard all computations done so far (since CoCoA-5 does not have a "save session" facility), and start a whole new session.

If I recall correctly, we imposed a limit on the stack height to protect the careless/inexpert user from his own mistakes (e.g. writing an infinitely recursive fn). It is not good that our solution impedes expert users trying to perform difficult computations.

Now I feel more "justified" in my preference for a built-in fn, but that doesn't mean that it is practicable...

Do the "quick fix"! Not satisfactory, but a proper soln is going to be costly :-(

Works OK up to stack size of about 5400; at 5500 I get a SEGV. Why????

Also get SEGV without --stacksize option; I have increased default max stack size to 5000 (because higher than that causes problems).

Makes no sense :-(
Aaaaahhh it seems that the C++ stack overflowed -- seems to need almost 3kbytes per CoCoA-5 stackframe (in a simple test on my machine). Why so much?

Adding note about original requester: andrei_zarojanu (at yahoo.com)
I'll email him about our partial solution -- hope it'll be enough for him!