Re: [Gretl-devel] functions vs commands (was Re: Octave support)
On Fri, 26 Feb 2010, Sven Schreiber wrote:
Allin Cottrell schrieb:
>
> I'm not sure exactly what should be done here, but I tend to agree
> that it would be messy to have "catch" apply to function calls,
> and I'll work on fixing that before the next release. We have a
> natural substitute in various matrix functions that return a null
> matrix on failure rather than flagging an error.
I like the rule that on errors functions return a null matrix, or an
empty list (do they?), or an empty string; and for scalar functions
would the error return value be NA? Obviously for many functions an
error cannot be represented simply by non-zero values as with mwrite().
We'll have to take a look at this with consistency in mind. As I
recall, the functions that return empty/NA say so in their
documentation.
>>>> In this case, admittedly, there's not much
justification for
>>>> function status -- other than a feeling of mine (anyone else?)
>>>> that it's better to keep the command namespace of manageable size.
>>>> I'm always somewhat reluctant to add a new command, but don't
feel
>>>> quite the same constraint with functions.
>>> 100% agree.
>> Yes I think that's wise. However, I'm not sure I understand exactly in
>> some cases why something is a command rather than a function then:
>>
>> * criteria
>
> It's gone in CVS, replaced by a packaged function.
Are you going to start shipping packaged functions with gretl?
Yes, criteria.gfn is in CVS and the current snapshot packages. But
I think this should probably be done only for packages that
replace old native functionality (for the present, at any rate).
>> * pvalue (although I see the analogy to the menu entry)
>> * (some of the transformation commands, although I see the case for
>> user-friendliness there)
>> * modprint (requires matrix stuff, so arguably is advanced anyway)
>> * sprintf (recent and advanced, and has natural return value)
>
> Some of these, I think, are simply "legacy". There's no real need
> to have sprintf, for example, in both command and function form:
> it's just that the command came first. Depending on how concerned
> we are with backward compatibility we could get rid of some of
> these.
I probably should add stuff like this on Jack's big-change wiki page.
Just one question inspired by pvalue: what about the command log and the
correspondence of CLI to GUI: does that mean that menu items should
basically be implemented as commands rather than functions?
Where possible, yes. However, some specialized things are
implemented as functions, for example the (new) command log
entries corresponding to the GUI filter menu items. And that
raises another wiki-related point: do we want to scrap the "set"
variables for the HP and BK filters now that we can do the
equivalent via arguments for hpfilt() and bkfilt()?
Allin