[Gretl-devel] Re: gretl functions and lists

[Gordon Hughes]

I would like to respond to Allin's note by drawing upon my experience 
of writing a variety of functions over the last 2-3 weeks.  In doing 
this I was aware of the dangers of overwriting existing variables 
when returning a list of variables created in the functions.  Hence, 
I would certainly favour the separation implied by the adoption of 
the PROTECT_LISTS 1 option.

However, I find the explanation and/or the handling of lists passed 
as function arguments rather clumsy.  My point concerns bullet 2 
close to the end of the note plus the code fragment for 
make_cubes.  It appears to imply that whenever one passes a list of 
series containing, say, the independent variables for an estimation 
function it will be necessary to include a loop over the list to copy 
the contents of this list to new variables inside the function.  Yet, 
the principle of encapsulation should mean that the list "xlist" in 
make_cubes should be a copy of the list provided as the argument, so 
the varcopy ought to be redundant in these circumstances.  Further, 
writing the loop at the beginning of any function would be a 
discouragement for novice users, among whom I would count myself 
though providing the necessary code in the documentation would reduce this.

But, I have a further point that I would like to raise.  When I was 
writing my stochastic frontier functions I found that it was 
necessary to write two different public functions to carry out what 
is essentially one task, which is tedious and incurs unnecessary 
overheads of function calls, etc.  The reason is that I wanted to 
return two types of information: (a) estimation results including 
parameter coefficients, variance-covariance matrix and 
log-likelihood, etc, and (b) residuals or the like (actually the 
inefficiency estimates).  Item (a) can be fitted into a matrix whose 
dimension depends upon the number of independent variables, while 
item (b) is a series or list of series whose length is equal to the 
number of observations in the sample.  So, the first function returns 
a matrix of estimation results, while the second function returns a 
list of residuals, etc.  Because the different sets of information 
have different dimensions, it is not practical to return it in a 
single matrix or list.

In the case of gretl's own estimation procedures this information is 
contained in $coeff, etc.  Would it be possible to provide a series 
of function placeholders such as $func_coeff, $func_uhat or 
$func_ret1-$func_ret9 which the writer of the function can fill, if 
desired, and the program calling the function can access after the 
function has been called.  This would deal with Sven's problem 
because one could prohibit a function from returning a list - a 
matrix or a series is not a problem because the matrix or series 
returned by the function is copied to the new matrix or series in the 
calling program.  Instead, the list created by my SFA efficiency 
function can be replaced by a single execution of the SFA estimation 
function which would put the residuals and efficiency estimates in 
$func_ret1, ... for retrieval by the user if wanted.  Of course, this 
information would be overwritten by subsequent function calls, but 
this is already the case for $coeff, etc.

Gordon