Recursive call of macros: is it legal?

[Sam Karli]

Hi,
I'm working on a window script that places sashes etc in a recursive way to allow user to make *any* kind of windows with unlimited number of horizontal/vertical divisions and any number and type of sashes.

Obviously this can be done by calling the itself in a recursive way getting its data form parameter arrays of the placed window instance.

The stuff works more or less, but my question is whether is it "legal" in a way that ArchiCAD doesn't consider it a Warning, or the Graphisoft not planning to prohibit it in a future version of ArchiCAD etc.

Obviously ArchiCAD doesn't check the size of the call stack and can be frozen with a bad (infinite) call.

But technically it seems to be easy to set up a relatively cheap and bulletproof watchdog to avoid infinite calls:

at the very beginning of the master script I put this:

MAX_CALLS = 10
a = vardim1(Teszt_A)
Teszt_A[a+1] = 1
if a > MAX_CALLS then end

Teszt_A being a parameter of the macro

and to the working part (anywhere)

call "Teszt" parameters all

In theory, regardless of the good or bad handling of call stack controlling variables of the actual implementation of the recursion algorithm, the "parameters all", if not forgotten, will pass the "Teszt_A" array to the child macro, and the master script of it will increment the size of it. By checking the size, we can put an end to the script if the array grows too large.

To be safe in theory we have to guarantee two things: not forgetting the all from parameters (thus passing the array to the child) and not overwriting the array with a smaller one.
Since this can be done easily and in a safe way I think recursion can be applied safely.

But is it considered to be legal?

[Ralph Wessel]

Sam wrote:
I think recursion can be applied safely.
But is it considered to be legal?

I wonder if the first question should be, "is recursion the best approach for this problem?"

Problems that seem intuitively recursive can also be solved iteratively, but in certain cases recursive code is easier to read and write. I don't personally feel GDL is intended to be recursive even if you can make it work. Have you considered solving this problem iteratively?

[Sam Karli]

@Ralph Wessel: Basically: No.

As I played around the problem, I realized the following things:

Theoretically we can solve it three ways:
-with a kind of iteration, within one single macro using a loop
-with recursive calls of subroutines within the same macro
-with recursive calls of (different) macros.

The situation is that if You try to solve the problem with the first two ways you have to simulate call stack frames, since in GDL all (local) variables have a marco-width scope, thus he following instantiations of local variables must be put into an array. (Local variables will look like localvariable[call_number] and with every next iteration call_number is increased) Needless to say, You will lose two dimensional arrays (one dimension is reserved for call_number).

On the other hand, for calling macros the call stack is handled well and local variables don't see each other directly (obviously).

So the only bottleneck is that is it a problem that there are two separate macros with the same name, but as i tested it around it behaved well.

All in all it worked for me.

[Sam Karli]

BTW I managed to make recursive calls using only GOSUBs (manually handling stack frames) and it is around 20 times faster than calling macros recursively.