Re: [Gretl-devel] functions vs commands (was Re: Octave support)
Riccardo (Jack) Lucchetti schrieb:
On Thu, 25 Feb 2010, Allin Cottrell wrote:
>
> On Thu, 25 Feb 2010, Sven Schreiber wrote:
>
>> Allin Cottrell schrieb:
>>
>>> mwrite(xy, "(a)dotdir/xy.mat")
>>
>> OT: I know about the return value of mwrite(), but this "feels" more
>> like a command than a function. Or to put it differently: if I
>> understand correctly you recently introduced more sophisticated error
>> handling ($error and stuff). I wonder whether a mish-mash is being born
>> right now, sometimes getting error codes from function return values,
>> and sometimes from accessor variables?
>
> I take your point that mwrite feels more like a command than a
> function. One reason it was done as a function is so that it could
> return an error code (rather than just bombing out on failure).
> Now that we have "catch" (see the manual) that could be
> reconsidered; but symmetry with mread (which is "naturally" a
> function) would argue for function status for mwrite.
Yes I think there are two different issues here: one is commands vs.
functions, and the other is how to do error handling. With respect to
the error handling one could argue to have only one way of doing things.
That would raise the question of what functions like mwrite() should
return instead. OTOH I can also see that catch is for commands, and
return values for functions -- but what about those functions that have
natural return values? What I really wouldn't like is to have catch for
commands and *some* functions, and for other functions using the return
value as error code. That I would find confusing.
...
> 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
* 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)
thanks,
sven