Persistence of local variables across iterations of a recursive function

[mikedr]

I have a question regarding how FM persists local variables ("$") across iterations of a script that's called recursively.

Say you have a script "dosomething". And in this script there's a loop:

set variable $counter=1

loop

perform script dosomething

exit loop if condition-is-met

$counter=$counter+1

end loop

Obviously this is pseudo code, but I hope you get the gist. My question is, say the first time the script calls itself. You have the original $counter, and the "new" $counter. Does the latter affect the former? That is, I know that "$" variables are local to a script, but do they persist "into" another script (such as a recursive call into the same script)?

Perhaps an easier question is script A calling script B. Say script A is:

set variable $counter=1

perform script B

In script B -- called from script A -- can the variable $counter (defined in script A) be "seen"? I'm hoping not.

[bruceR]

No, it  cannot.

FWIW, I prefer this form; unless you have some other way of specifying the exit condition.

(pseudo code)

 

Set variable $counter; 0

Set Variable $max ; 100 # or whatever you need

Loop

 Exit Loop If ( Let( $counter = 1 + $counter); $counter > $max)

 Now do stuff

End loop

[mikedr]

The problem is that I need recursion. I'm navigating a tree. Each node is a parent to 0+ other nodes. So the idea is to keep calling the same script (starting from the highest node) passing the node value, until you get to the end (where there are no children nodes).

I did to a quick mockup of my script A-->script B scenario, and this worked. I.e., local variables of script A were not seen in script B. But I haven't tried recursion of a script yet.

Basically, I'm just asking if Filemaker Pro follows basic programming precepts as to each called instance of a script has its own variables, apart from those of the other instances of the same script.

[LaRetta]

I'm navigating a tree. 

 

It sounds more like you need GTRR ( Go To Related Record ) through relationships.  Understanding certain principles, such as good scripting practice is helpful but by only speaking in abstract, we can only answer in abstract.  If you are newer to the 'ways of FileMaker', abstract can send you down the wrong path.  

 

How about a concrete real example of what you are trying to accomplish instead?  FileMaker is not programming as usual.  Not at all.  :-)

[comment]

Basically, I'm just asking if Filemaker Pro follows basic programming precepts as to each called instance of a script has its own variables,

 

Yes. Local (single $) $variables are scoped to the currently executing script. If you do a recursive call and your exit condition is based on a local $variable reaching some threshold, you will end up in an infinite loop.

[mikedr]

Thanks!  I was able to get the recursion working perfectly. 

 

EDIT: please ignore the following; I'm reposting this as a new thread.

 

However, I'll take up LaRetta's invitation, as I think I'm constructing a Rube Goldberg-esque solution to my problem.  Here's the application domain.  I have a table of records that correspond to patent applications, which are commonly referred to as matters.  A matter can claim (but does not have to) immediate priority to one and only one other matter.  However, more than one matter can claim priority to the same matter, and a matter that has matter(s) which claim priority to it can itself claim priority to a matter.  When a matter claims priority to another matter, this means that the former matter is of lower priority than the latter matter.

 

I realize this is confusing, so here's a concrete example that I've been using for testing purposes.  Say there are seven matters A, B, C, D, E, F, G.  B and C claim priority to A, and are thus of lower priority than A.  D and E claim priority to B, and are thus of lower priority than B and A.  F and G claim priority to E, and are thus of lower priority than E, B, and A.

 

For what it's worth, I created another table called priority, which lists two matters, the matter claiming priority, and the matter to which it claims priority.  In hindsight, this is perhaps not needed, since in my main matter table, I could simply have a matter refer to another matter to which it claims priority.

 

Now, the problem.  Per the concrete example listed above, the result of matters claiming priority to other matters effectively results in a hierarchical tree.  I want to list all the matters that are in the same tree -- that is, all the matters in any priority chain.  So, regardless if I start at matter A, B, C, D, E, F, or G, I end up with the same list of matters.

 

Here's how I've done this.  I have a first script that finds the highest priority matter in the tree.  So, if you started at A, you're OK, because A is the highest priority.  But if you start from E, say, it would find B as being of higher priority, and then finally find A as being of highest priority.  That is, regardless of whether you start at A, B, C, D, E, F, or G, you always end up at A.

 

Then, this script calls a second script that recursively calls itself.  The second script has a parameter that is a current matter.  It locates any matters that claim priority to the current matter.  If there are any such matters, for each matter it calls itself again, to determine whether there are any matters that claim priority to these matters.

 

This indeed works as expected.  Once we get to A in the first script, the call to the second script passing A finds B and C.  For each of B and C, the second script calls itself.  When the second script is operating on B as the current matter, it finds D and E, and when operating on E as the current matter, it finds F and G.

 

What I don't like about this approach is that there is a *LOT* of searching going on.  But it does work. 

 

The idea is that once I get all the matters in a family -- i.e., all of A, B, C, D, E, F, and G -- I can list these applications in a layout, and long-term, call some (external) tree building tool appropriately to create a visual representation.

 

Critically, though, a user is just going to specify at most one priority relationship for any given matter, that the given matter claims priority to (and thus is of lower priority than) another matter.  From these priority relationships, then, I need to figure out the family of matters.

[mikedr]

Question -- should I post my comment above as a new thread? 

[Wim Decorte]

If it is a follow-up to the original question, then here is fine.  If it contains a new question however, start a new thread.

[mikedr]

Yeah, I think I'll repost this as a new thread, because it's basically a new question that's just tangentially related.

[Lee Smith]

Hi Mike,

 

New Thread or the Original Thread, that is the question?

 

You also need to consider if there is information in the original thread that needs to be known in order to help with the new question.

 

The Members should not have to read the original thread to see what has been asked and answered.

 

HTH

 

Lee

[mikedr]

It's all in there.