Re: [Gretl-devel] bad bug (because it fails silently)
On Fri, 30 Oct 2015, Sven Schreiber wrote:
Am 30.10.2015 um 02:32 schrieb Allin Cottrell:
> On Thu, 29 Oct 2015, Allin Cottrell wrote:
>
>> On Thu, 29 Oct 2015, Sven Schreiber wrote:
>>
>>>
>>> <hansl>
>>> bundle b
>>> b.cutoff = 0.05
>>> ols lhs const rhs1 rhs2
>>> omit --auto=b.cutoff
>>> </hansl>
>>>
>>> Instead 'omit' will use the default value of 0.10 in this case.
>>
>> This should not fail silently, agreed. Now in git it fails noisily:
>>
>> ? omit --auto=b.cutoff
>> b.cutoff: invalid option argument
>
> Well, OK, it might as well succeed since it's not that difficult to
> arrange. That's now in git.
Hm, I'm not sure that's the best course of action. We had the issue before
that "you pay a price for the simplicity of commands". For example,
var b.lagorder series1 series2
isn't possible, either.
IMHO either bundle elements (of the right type, of course) should be possible
everywhere, or they should be banned everywhere. Of course I'd like the
"possible everywhere" option, but I can understand that it's difficult and
error-prone. So I would rather have a clearcut rule; explicit errors are not
a problem in my view. Any partial solution isn't helpful for really mastering
hansl.
I take your point; maybe we should back off on this until we've
considered it more carefully. Let me comment on this a but more
generally.
In general, when a gretl command calls for a scalar argument (either
"in line" or attached to an option flag) you can give that either in
numerical form or as the name of a pre-defined scalar variable. (If
there are any remaining contexts where the latter is not accepted I
would regard that as a bug.)
However, by popular demand we have extended that a bit, so in some
contexts an expression that evaluates to a scalar is accepted, for
example in the limits of iteration, as in
loop i=1..$nobs/2
One question is how far we want to go in this direction. It turns out
that it's quite easy to make that extension for option-flag arguments
(or at least seems easy, there may be cases where this causes
problems).
As regards bundle-members, I don't think it's going to be worth
treating them as a special case: they require an evaluation process
and so might as well be passed through "genr". I mean, when we come
across a string that's neither numeric nor the name of a scalar
(things that can be checked pretty quickly) we have no idea at first
whether it represents bundle.member (or bundle["member"]), or some
other expression that evaluates to a scalar, or nonsense. But we have
a parser to handle all those cases, so I think we should either use it
or not, rather than trying special means to detect stuff inside
bundles.
Allin