EViews.com

I'm struggling to make sense of how scope works in local subroutines. I get an error that I don't understand. I have two files: parent.prg and child.prg.

parent.prg
child.prg
The call to parent1 works just fine and results in a dialog box reading "MY_STRING". But the call to parent2 first results in an empty dialog box and then throws an error reading 'MY_STRING is not defined in "DELETE MY_STRING" in CHILD.PRG on line 8.' Is this the intended behavior?

Pretty much. If you run in debug mode and step through, you can see what happens. Local parent calls child, which means that child is local, which means that no created variables have workfile scope.

In debug mode, it's pretty clear. But still rather confusing :-) If I'm understanding things correctly, objects in local subroutines work differently from objects outside local subroutines and never appear in a workfile at all. And that is why they aren't listed when using @wlookup. As a program can be called from within a local subroutine, this essentially means that I can never trust @wlookup.

I stumbled onto another issue, even more confusing than the last. This time there are three files: parent.prg, child_without_sub.prg, and child_with_sub.prg.

parent.prg
child_without_sub.prg
child_with_sub.prg
The call to the subroutine exec_child_without_sub works just fine, but the call to the subroutine exec_child_with_sub throws an error: A is not defined in "!B = A" in PARENT.PRG on line 10. What is happening here? The subroutine child_sub in child_with_sub.prg doesn't even do anything with the scalar A. The error persists even if I make child_sub a local subroutine that doesn’t even have access to A.

The child subroutine inherits the "local" of the calling parent, and thus variables created inside the child subroutine are not available outside of that subroutine, even to the parent.

But the call to exec_child_without_sub works just fine even though the parent is a local subroutine. Should really the mere existence of a subroutine call in child_with_sub.prg change the scope of A?

Gareth, I presume that the "child subroutine" that you refer to is the subroutine child_sub in child_with_sub.prg and that the "calling parent" is either

1. child_with_sub.prg itself or
2. the local subroutine exec_child_with_sub in parent.prg.

In either case, I don't understand how your explanation relates to the setup that I specified in my post: No variables are created inside the subroutine child_sub.

And if it simply was the call structure ("local subroutine executes program") that was the problem, then it is odd that the scalar A is available after the exec command in exec_child_without_sub but not in exec_child_with_sub. The only difference between the programs that those two subroutines calls (i.e., child_without_sub.prg and child_with_sub.prg) is a call to a subroutine that doesn't do anything. It is almost as if there was a limit of two (2) in "scope depth".

No, you're right, that is weird.


As an aside, I tend not to use local subroutines at all - they can be very frustrating to work with.

Can we consider this my bug report? Or should I submit something more formally?

Consider it reported.

This issue seems related. Again, I have three files: parent.prg, alert.prg, and child.prg. Running parent.prg generates a stream of dialog boxes in two batches.

The first batch calling a_caller_sub is straightforward: The scalar a is always observable and the scalar b is only observable when child.prg calls a_child_sub and not when it calls a_local_child_sub.

But in the second batch calling a_local_caller_sub, the first case is behaving strangely: Now, a_child_sub can't observe the scalar a but it can observe the scalar b.

(Admittedly, this example could have been streamlined )

Have you made any progress with these bugs?

No. It will be some time before they are addressed.

Any progress?

Not yet :/