On Mon, 7 Dec 2015, Riccardo (Jack) Lucchetti wrote:
Dear all,
I'm aware that backward-incompatibilty should in principle be
avoided. However, it occurred to me that we introduced string
arrays only after (more or less) clever workarounds to their
absence. Typical cases are:
* the modprint command
* the varname() function (yes I know about varnames(), but it's a hack)
* the jsonget() function
* the labels command
* the colnames() and rownames() function
etc etc.
Clearly, a redesign of all these would be optimal, but it would
involve a major revision of hundreds of scripts out there;
however, like always, the sooner this is done, the better.
Opinions?
Sven's response included this: "In my view the array support in
gretl is still not mature enough. For example, just recently (and
still undocumented?) the possibility to assign array elements
directly in one go was introduced."
I take Sven's point: Jack's question should be addressed but first
we need to put arrays on a more regular, better documented footing.
In that context let me pose a question.
As a reminder, the undocumented mkarray() function allows you to
define an array by listing its members as arguments, as in
strings S = mkarray("foo", "bar", "baz")
which is equivalent to
strings S = array(3)
S[1] = "foo"
S[2] = "bar"
S[3] = "baz"
Before I document this let me float an idea. We could rename
mkarray() as just array(), but preserve the existing functionality
of array() -- that is, to create an array of specified size with
each member initialized to an appropriate "empty" value -- in this
way: if the function is given a single, scalar argument it acts as
array() currently acts, otherwise it acts as mkarray(). [Note that
we don't accept scalars as arguments to mkarray(); you can't have an
array of scalars as such.]
Question(s): is this too tricksy? And if it is too tricksy and we
want two separate functions, is the name "mkarray" alright for the
new one or can anyone think of a better name?
Once this is resolved let's come back to Jack's question.
Allin