Sorry, didn't manage to respond to this earlier, but here goes.
On Thu, 17 Jul 2008, Gordon Hughes wrote:
The difficulty with the use of pointers rather than $ accessors
is really one of how to provide a single package which
implements the basic procedure for the novice user while giving
the expert user the ability to recover additional results.
adding the requirement to define additional variables and
provide the relevant pointers the function becomes less easy to
use for someone who just wants to run a simple estimation and
has no requirement for anything beyond the basic printed
output...
There's something that's present in the manual but maybe not
obvious. If you're writing a function that provides some "basic"
output but also offers optional info that's likely to be of
interest only to experts, the trick is to (a) make the extra info
available via pointer arguments, (b) give those pointers a default
value of "null", and (c) make sure they come at the end of the
list of parameters. Then the user does not have to mess with them
at all.
For example, a function with this signature
function myfun (list L, matrix M,
matrix *A[null], matrix *B[null])
might simply be called as, say,
myfun(xlist, Xmat)
since trailing arguments that have default values can be omitted
altogether. So, if I'm understanding your point right, you really
shouldn't need two versions of the function.
In the gretl GUI, the call dialog for such a function (assuming it
has been packaged) will show the pointer arguments, with the
"null" default in place. One possible refinement of the GUI would
be to separate optional pointer arguments in such a way that
things don't look "too complicated" to the average user. For
instance, the function call dialog could have a "notebook"
structure, with such arguments placed under a second tab.
If that sounds useful, I'll have a go at implementing it.
Allin.