Re: [Gretl-devel] parser problem
On Thu, 25 Apr 2013, Sven Schreiber wrote:
Am 25.04.2013 15:43, schrieb Allin Cottrell:
> On Thu, 25 Apr 2013, Allin Cottrell wrote:
>
>> On Thu, 25 Apr 2013, Sven Schreiber wrote:
>>
>>> I was mixing up the parentheses and tried to access a single value of a
>>> series like this:
>>> x(1995:1) -- instead of x[1995:1]
>>>
>>> The problem is that gretl did not complain [...]
>>
>> We could, I suppose, make an internal distinction between
>> "general" scalars and scalars that have been converted from
>> observation identifiers, and limit the contexts in which we
>> accept the latter.
>
> I've done something like this in CVS, and done a certain
> amount of checking for bad side-effects. OK so far, but more
> testing would be good.
Thanks for the explanation of the cause (other email).
So the parsing ordering seems to be (1) internal conversions (here: to
obs index), (2) syntax-check (maybe implicit in the evaluation step). My
intuitive reaction would be that this ordering should be reversed; first
a syntax check (insofar as it's possible), and only afterwards do any
internal conversions, because the syntax is an "external thing" if you
know what I mean.
Actually the "something like this" that I implemented is a bit
different from what I first stated.
Before the change: when parsing numerical input (other than in
the context of matrix subscripting, where ':' has its own
special meaning) we don't immediately reject ':' but we record
the fact that we got a colon in the input stream. And once
we've finished assembling the "numerical" string, if we got a
colon we try interpreting that string as an observation
identifier. This will fail and generate an error if there's no
dataset in place, or if the frequency is wrong, or if the
index is out of bounds, but if it's OK as an obs identifier we
convert it to a straight numerical index and treat it as a
scalar thereafter.
After the change: as above, except that if we validate the obs
identifier we record it internally as a string, not a scalar.
Then when it comes to evaluating, e.g.,
scalar xt = x[1995:1]
we find the string "1995:1" which converts to an index in
situ. (This is OK since a string is in general acceptable as
an obs identifier.)
On the other hand, if we try to evaluate, e.g.,
foo = x(1995:1)
the form "x()", for x a series, leads us to expect a lag/lead
specification, which requires a scalar value. We find a string
where there ought to be a scalar, and we error out.
Allin