On Thu, 25 Oct 2018, oleg_komashko(a)ukr.net wrote:
Dear all, since the current behavior for
all functions is override series(int_lag)
behavior. A possible solution would be
1) for series(int1 to int2)
to protect it from functions, since int1 to int2
can be distinguished from functions arguments
In principle, "int1 to int2" can be ruled out as a valid function
argument, true. But the parser works left-to-right with only minimal
look-ahead (what's the next character?). It would not be easy to
support fold-back, as in "Oh, we hit an error, maybe we can fix it by
going back and reinterpreting something." (But maybe...)
In the meantime, in git, I'm exploring some other heuristics. Inside
functions I think the prior preference for the function(args)
interpretation should be reversed -- so series(lags) preferred -- if
the function in question is not built-in. This is because a function
author ought to know what all the series in scope are called (since
they're either arguments whose names he has chosen, or series he has
defined), but he won't necessarily know the names of any functions
that might be floating around in the caller's namespace.
2) for series(int) in each call (for coinciding names only)
type warning:
series(int) has been interpreted as function call
rename series if you want obtain its lags
Yes, that sounds suitable for cases where we impose the function(args)
interpretation under ambiguity.
Allin