>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.

For immediate scripting, I think the order of priorities is not
very important, since a user can change the both function and
variable names
But for packages I can not foresee what series names will be
in a file opened by other user

By the way, if it will be possible to use both  fun() and pkg::fun()
this can solve the problem for package functions
Oleh

On Thu, 25 Oct 2018, oleg_komashko@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
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel