topic Re: Question about Arrays & Subroutines in GDL

Question about Arrays & Subroutines

Nader Belal — Mon, 26 Sep 2022 20:45:15 GMT

Hi there,

I would like to ask why the creation of arrays in a sub-routine in Parameter script as in the following example is generating an error ("Incompatible array dimensions")



some script

if condition is met then
	gosub 001

	_tempArray = _origArray		!<--both arrays are one dimension
endif

some script

end

001:

dim _tempArray

return

Re: Question about Arrays & Subroutines

Jochen Suehlo — Wed, 02 Sep 2020 13:35:40 GMT

In my experience it happens, that arrays defined in a subroutine where not recognized in parts of scripts that are above the subroutine (in the text order).
Example:

gosub 100
_newVALUE = _tempArray[1]		
end
100:
dim _tempArray[]
_tempArray[1] = 2
return

But if you change this into this, it works:

gosub 100
gosub 200
end
100:
dim _tempArray[]
_tempArray[1] = 2
return

200:
_newVALUE = _tempArray[1]	
return

This is a weird thing, but I think, it is a bug.

Re: Question about Arrays & Subroutines

Nader Belal — Wed, 02 Sep 2020 16:29:45 GMT

@Joachim Suehlo

Thank you a lot.

Re: Question about Arrays & Subroutines

leceta — Tue, 06 Oct 2020 11:55:01 GMT

From the book GDL Handbook, by Andrew Watson, 3.5.Scope, pages 36-37

Array variables have some interesting characteristics when it comes to scope. You must define an array before you can use it, which stands to reason. You can define an array variable in a sub-routine (we’ll discuss sub-routines later) but it’s best to define arrays in the main script. If you define an array variable in a sub-routine and then try to use it in the main script, error messages will pop up when you try to save the object.

and later:

The variable must be declared at a point in the script that comes both physically and logically ahead of the point at which it is used.

Re: Question about Arrays & Subroutines

Peter Baksa — Tue, 06 Oct 2020 15:07:44 GMT

Joachim wrote:
This is a weird thing, but I think, it is a bug.

This isn't a bug, it's a limitation. The order of statements can depend on parameters, it is only known at run-time. Variables mustn't change their types during run, the best the interpreter can do is check the code line-by-line (there are simple cases when the order of execution is evident, but it can get complicated very easily). If it didn't do this check, it would be possible to get error messages only by some parameter states, which would make them very hard to detect and understand.