Passing information between the edit and a subroutine
When you use subroutines, Quantum differentiates between variables defined in the
variables file or before the
ed statement and those defined after the
ed or
subroutine statements. For more information on the variables file, see
Creating new variables, and
Files used by Quantum.
Variables defined in the variables file or before ed are called external variables and may be accessed and changed by statements within a subroutine. Variables defined after ed or inside a subroutine are local variables and cannot be changed by a subroutine. For example:
real cost 1
int items 1
ed
int nshop 1
/* edit statements
return
/* subroutines
end
The variables cost and items are defined before the ed statement. This means they are external variables and can have their values changed by a subroutine. The variable nshop is defined after ed so it is a local variable. This means it cannot have its value changed by the subroutine, even though its value can be passed to the subroutine for use by it.
Information stored in external variables is always available within a subroutine, and may be accessed and changed regardless of whether you pass it as an argument to the subroutine. For example, if you define an integer variable called items in the variables file, you can read its contents and change them in the subroutine even if you do not include items as part of the call statement.
You might write:
call sub1
return
subroutine sub1
if (items.gt.5) emit c134'1'
return
end
This checks, inside the subroutine, whether the value of items is greater than 5 and, if so, inserts a ‘1’ in column 134. You do not pass the value of items to the subroutine because it is an external variable which is available to the subroutine as a matter of course. Because items is an external variable, you can change its value in the subroutine if you want. For example, you can reset it to zero.
Local variables which are required in the subroutine must be passed to the routine as arguments. If the items variable was defined after the ed statement, you have to name it on the call statement and on the subroutine statement thus:
ed
int items 1
call sub1(items)
return
subroutine sub1(items)
if (items.gt.5) emit c134'1'
return
end
This example performs the same task as the previous one. The difference is that this time items is a local variable, so you must pass it to the subroutine. Once inside the subroutine, you cannot change the value of items in any way.
In these examples, you do not need to pass c134 as an argument, because all cells in the C array are external variables.
When you use a subroutine which requires arguments, be sure that you call it with as many arguments as are listed on the subroutine statement for that subroutine. If you give too many or too few arguments, errors occur.
For example:
call conv(gallons,liters)
.
subroutine conv(gallons,liters)
is correct because it calls the subroutine with the same number of arguments as there are in its definition, but:
call conv(aa,bb,cc)
.
subroutine conv(aa,bb,cc,dd)
is incorrect because it calls conv with one argument fewer than its definition specifies.
When you return to the edit from a subroutine, any changes made to external variables will still exist, but values assigned to local variables defined in the subroutine will not be accessible from the main edit program. For example:
call sub1
return
subroutine sub1
int doneit 1
if (items.gt.5) emit c134'1'
items = 0
doneit = 1
return
end
Once the subroutine has been executed and control has returned to the edit, the value of items will be zero but doneit will have no value at all.
See also