with a cvs build from 2 min ago: when (in a function package) I try to edit a function, some changes are persistent, others are not. I can change (in a function argument context) "list restr_exo" to "const list restr_exo", but not "list restr_exo" to "list restr_exo[null]".

On Wed, 24 Jan 2007, Sven Schreiber wrote: > Just found out something much more serious!!! After deleting some old > versions of function packages from the package manager, the other > packages are (partly) broken! Could it be because they share some > common helper functions? Yes. I'm about to try fixing this. There are some problems right now (as you found!) when packages load functions having the same name as other functions already present.

even though the default [null] for the list is set, executing the function package shows another named list for the parameter restr_exo.

1. package the following example function: function test(list myl[null]) if nelem(myl) != 0 print "This shouldn't be printed if the user didn't touch the default input." endif end function 2. open some datafile and create an arbitrary but non-empty list named "spam" 3. execute the function package from step 1; list "spam" appears as selected in the list input drop-down menu So the function package does not honor the [null] default setting. Nothing too serious, but a little annoying.

On Fri, 26 Jan 2007, Sven Schreiber wrote:

> > So the function package does not honor the [null] default setting. > > Nothing too serious, but a little annoying. Thanks, I now see what you mean. It seems to me: whether this is a problem or not is a bit subtle, and depends on the context. When a function gives a [null] default for a list argument, is it saying A or B? A: "I'd normally expect a list here, but if you don't want to give one I can manage without" B: "A basic invocation of this function wouldn't have a list here, but if you want to get fancy you can specify one" I presume you have case B in mind, but in case A the behaviour you describe you not, I think, seem wrong.

On reflection case B seems more likely, so I've made things behave the way you were expecting.

On Sat, 27 Jan 2007, Sven Schreiber wrote: > -- ok, so IMHO gretl should not allow to leave the return value name > empty in the package call GUI. Right now it seems possible to not > provide a name for the returned object and still call the function. As > a result it appears that the return value is discarded. I cannot see > the use of that behavior, so I propose that gretl catches that > specific user input error. Not sure I agree on that. A function may, for example, print something the user is interested in (e.g. some sort of hypothesis test) and offer a return that is only of interest to experts (say, a vector of relatively "raw" values that could be further processed). Why should the GUI user be forced to assign the return, when the script user is free to ignore it?

On Sat, 27 Jan 2007, Sven Schreiber quoted:

>> >> Why should the GUI user be forced to assign the return, when the script >> user is free to ignore it? and wrote: > Good point! On the other hand, there may be some packaged functions whose whole point is to return something, and where it doesn't really make sense to ignore the return -- perhaps they don't print anything. I guess that is what you were thinking of. Maybe (perhaps later) we should provide a way for a function author to indicate whether the return can sensibly be ignored or not -- some suitable inflection on the "return" statement?