Re: [Gretl-devel] functions vs commands (was Re: Octave support)
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().
>>> 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?
> * 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?
thanks,
sven