Re: [Gretl-users] about arrays as argument of yahoo_get
On Fri, 19 Aug 2016, Sven Schreiber wrote:
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.)
Arrays are preserved by --preserve.
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.)
Yes, one can argue that it would make more sense for "nulldata" just
to destroy the existing dataset (if any) -- which means destroying any
lists too -- but leave other objects alone. We have "clear" if you
want to clear out the entire workspace.
On the backward compat side, changing the default could break some
scripts, though maybe that's not very likely. Example
<hansl>
...
string s = "whatever"
...
nulldata 100
...
series s = normal()
</hansl>
That's OK at present, but would become an error if "nulldata" didn't
destroy the string s.
One other consideration: at present, loading a new dataset from file
(via "open" or the GUI equivalent) clears out the entire existing
workspace, unless --preserve is used. The current handling of
"nulldata" is consistent with that behaviour.
So actually I'm not sure about this ;-)
Allin