In my opinion the answer depends on quantity of work and
possible problems resulting from less strict checking
A a variable is attributed by 'name', a function is attributed
by 'name('. At present I can't imagine what problems can
create even
matrix sin = seq(1,3)
Parser MUST distinguish sin from sin(

Another question
Suppose pack1.gfn and pack2.gfn both has
private_pack private functions
I think the both should be mutually invisible

Yet another one
Suppose, pack1.gfn has public1() public
What to do if a user makes in a script

include pack1.gfn
function ret_type public1 ....
end function

In my opinion, running function segment
should give error:
function 'include pack1.gfn' is already defined in pack1.gfn

Suppose, pack2.gfn and pack2.gfn both have
Suppose we first run
include pack1.gfn
include pack2.gfn
There should be a warning
public1() from pack2.gfn has shadowed
the same name function from pack2.gfn

For a user to avoid ambiguity she should
can use something like this



23 жовтня 2018, 17:10:32, від "Allin Cottrell" <>:

On Tue, 23 Oct 2018, wrote:

> I've just checked:
> It's already present in 2018a
> (I have several portable versions for checking)
> Oleh
> 23 жовтня 2018, 14:39:04, від "Sven Schreiber" <>:
> Am 23.10.2018 um 13:31 schrieb
> Dear all,
> If we create a function having a name coinsiding
> with the name of a local variable in a package,
> Right (confirmed), this shouldn't happen.

Hmm, so what do we think ought to happen? Should this warning be 
scrapped altogether, or should its scope be confined in some way? (And 
if so, what way?)

Mostly, defining a variable with the same name as a "visible" function 
won't cause trouble, since the identifier will be handled differently 
depending on whether it's immediately followed by left parenthesis. 
But that can mess up with lags:

function void den(scalar x)
    eval floor(x)
end function

nulldata 10
series den = normal()   # warning but no error
series denlag = den(-1) # fails

-> "The function den does not return any value".

One possible thought is that function-package code shouldn't "see" 
user-defined functions outside of its own space. But that's probably 
too restrictive: what about package dependencies, and packaged 
functions that take a user-function as a "callback" argument?

Gretl-devel mailing list