Re: [Gretl-devel] update on gretl functions and lists (long)

On Wed, 23 Jul 2008, Allin Cottrell wrote: On this, see below. Ok. I see your point. However, it is absolutely imperative that anyone who writes new functions or maintains existing functions is made aware that there will be a breakpoint in the not so far future. To help with the transition, they are strongly advised to check all the functions they've got with PROTECT_LISTS as true. Nice idea. Ok: now, the most important things I'd like to see in gretl 2.0. Please note that the following list (ha ha) is a quasi-random collection of things that have crossed my mind when writing scripts, and shouldn't be interpreted as definitive (in fact, I have a few more, but the're not as important, and this message is too long already). The deeper the discussion, the better. 1) structs, or arrays, or both Writing complex functions would be simplified enormously if we had a way to cram together items of different type in a single wrapper. Think, as a very contrived example, if you wanted to re-implement OLS as a function. The function would return an object inside which you'd have a vector of coefficients (a matrix), the residuals (a series), the number of observations (a scalar) and so on. For people who are unfamiliar with the C source: this is just the way things are already handled internally. When you use the $coeff accessor, the relevant matrix is retrieved from a complex object, called a MODEL, which contains everything. Ideally, the neatest way to handle this would be having the equivalent to a C "struct", that is a container in which each slot has a name and is of a certain type, so continuing with the previous example you'd have something like <pseudo-script> struct my_own_model = { \ matrix beta, series resid, scalar T } my_own_model model0 scalar model0.T = 123 scalar df = model0.T - rows(model0.beta) <pseudo-script> Alternatively, we could have an "array" type à la Ox, in which you don't have identifiers, but only typeless items, which you would refer to by number: <pseudo-script> array model0 = {} scalar model0[1] = 123 matrix model0[2] = beta scalar df = model0[1] - rows(model0[2]) <pseudo-script> Either of these construct would also have the added benefit of simplifying function syntax; today, if you want to write a function that returns (possibly many) matrices, your best bet is in many cases to use (possibly many) matrix pointers as arguments. If we manage to implement the above, everything becomes much cleaner. 2) private functions Personal experience, plus Stefano and Gordon's recent efforts, convinced me that in order to expose a sufficiently complex function to the user, you need on average 4-5 "internal" functions. Ideally, we should have that when you "include foo.inp" file, you only get the functions that are _in_that_file_; if foo.inp includes bar.inp and baz.inp, then those functions are available to the functions contained in foo.inp, but not to the top-level file. This may be difficult to implement, though. 3) package management I have already discussed with some of you my ideas on how packages should be handled. This message is already very long, so I'll cut to the gist. In one word: discipline. User-written functions should reside in a very specific subdirectory (say, ~/gretl/include) and must be organised more rigidly than the current anarchy. The point above (private functions) is especially important. In the unlikely case you're wondering what my other ideas are, I'll just give you a few headings: - slicker treatment of optional parameters - dynamic evaluation blocks - pointers to functions - more comprehensive set of string functions - seq() should return a column - switch/case (but if/elif is probably just as good already) Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti