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