Control variables are not local in a local subroutine

[etienne]

Hi,

In a local subroutine, the control variables are not local, which may lead to problems if a subroutine calls another one which use control variables named identically. I think this is quite likely to happen if for loops are used in generic subroutines shared between different programs though the use of he include command (as was my case).

This undesirable behaviour is present in both EViews versions 7.2 and 8.

Here's a simple example:

Code: Select all

subroutine local test1 %i = "a" !i = 1 endsub subroutine local test2(string %out) %i = "b" !i = 2 call test1 %out = %i + @str(!i) endsub %str = "" call test2(%str) @uiprompt(%str)

The message box will display "a1", while if I remove the call to test1 in test2, it will display "b2". This means that the control variables in test2 are modified by the call to test1, even though test1 is declared local.

As a workaround, for the moment, I use the fact that the variables appearing as arguments are truly local and behave correctly, so I put the control variables as arguments. To keep the subroutine "interface" clean, I define a first routine with the expected arguments, and this routine calls a second one which includes additional arguments for the control variables. For example, the above example would become like this:

Code: Select all

subroutine local test1 call test1_args("", 0) endsub subroutine local test1_args(string %i, scalar !i) %i = "a" !i = 1 endsub subroutine local test2(string %out) call test2_args(%out, "", 0) endsub subroutine local test2_args(string %out, string %i, scalar !i) %i = "b" !i = 2 call test1 %out = %i + @str(!i) endsub %str = "" call test2(%str) @uiprompt(%str)

It works, displaying "b2", but it's both laborious and inelegant, especially when there is a larger number of control variables. Another solution could be to name control variables with long, complicated names that would effectively guarantee their uniqueness. I don't like that, because it increases much the risk of making a typo when entering the control variables' names, and since EViews will not complain and use simply use that 'new' variable, giving it a value of 0 or "", this could lead to errors that are not always easy to detect.

Best regards,

Étienne

[EViews Gareth]

Correct.

Local subroutines only create local workfile objects, not program variables.