On Aug 18, 2016, at 6:55 PM, guido giaume <guido(a)giaume.it&gt; wrote: Dear all I spent some time before i realized the position of a declaration of array as argument of a function seems to be very critical. I mean that this following script is NOT working "as is", but if i change the position of the declaration it works. ----------------------------------------------------- #ARRAY DECLARATION far from yahoo_get strings P = defarray("A2A.MI", "ANIM.MI") # OPEN SET 10 DAYS nulldata 10 # TIME SERIES setobs 5 2016-07-01 --time-series # CALL yahoo_get include yahoo_get.gfn ######## QUESTION ITEM ######## strings P = defarray("A2A.MI", "ANIM.MI") #DOWNLOAD LOOP loop i=1..nelem(P) A=yahoo_full(P[i]) endloop ------------------------------------------------------------ you easily can verify the script isn't working BUT if I put the array declaration near the yahoo_get the script works. ----------------------------------------------------- ######## cut off the previous declaration ######## strings P = defarray("A2A.MI", "ANIM.MI") # OPEN SET 10 DAYS nulldata 10 # TIME SERIES setobs 5 2016-07-01 --time-series # CALL yahoo_get include yahoo_get.gfn #ARRAY DECLARATION near yahoo_get strings P = defarray("A2A.MI", "ANIM.MI") loop i=1..nelem(P) A=yahoo_full(P[i]) endloop ------------------------------------------------------------ now it works. So maybe it's a trivial subjetc but i will appreciate some help to understand why it happens. Cheers Guido _______________________________________________ Gretl-users mailing list Gretl-users(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-users

Am 19.08.2016 um 01:24 schrieb Summers, Peter: > The problem is where your "nulldata" command is. In the first > version, it wipes out the array declaration. You should either put > that command first or use the --preserve option for it (ie, "nulldata > 10 --preserve") which will keep previously declared variables (I > think arrays are preserved, but I could be wrong about that). I think they should also be preserved and if not, it would be a bug in my view. (Too lazy to test right now.)

But with respect to "nulldata", I think the reason that it destroys previously defined variables by default is just historical. I would be in favor of changing the default because that seems to be a common source of errors and misunderstandings. However, since I'm also known to value backwards compatibility my suggestion is to introduce a new option to "nulldata", namely something like "--reset-session". This new option would currently not actually do anything because it would be equivalent to the default. But in the user guide it could be presented as good practice and it would make it clear what's happening. Later on some warning could be issued by gretl when "nulldata" is used without any option, explaining that the default behavior might be changed sometime in the future. (But this second step is optional.)