Am 23.10.2018 um 13:31 schrieb oleg_komashko(a)ukr.net: Right (confirmed), this shouldn't happen. For me this is with the Oct 16th snapshot. thanks, sven

On Tue, 23 Oct 2018, oleg_komashko(a)ukr.net wrote: 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: <hansl> function void den(scalar x) eval floor(x) end function nulldata 10 series den = normal() # warning but no error series denlag = den(-1) # fails </hansl> -> "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? Allin

On Tue, 23 Oct 2018, Sven Schreiber wrote: [...] I'm pretty sure there isn't. Maybe we should just confine the diagnostic to the case where a function and series share a name, and we come across an instance of "shared_name(". As things stand the function will be called by preference in this case: it might or might not work in context, and might or might not be what the user actually wants, so perhaps this should be an error rather than just a warning. Allin

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 function What to do if a user makes in a script include pack1.gfn function ret_type public1 .... body 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 public1() Suppose we first run include pack1.gfn then 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 pack1.public1() and pack2.public1() Oleh 23 жовтня 2018, 17:10:32, від "Allin Cottrell" <cottrell(a)wfu.edu&gt;: On Tue, 23 Oct 2018, oleg_komashko(a)ukr.net wrote: 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: <hansl> function void den(scalar x) eval floor(x) end function nulldata 10 series den = normal() # warning but no error series denlag = den(-1) # fails </hansl> -> "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? Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

lag has description and 'patent' attribute within Possibly, tokenizer could somehwo play with it Also, if I am not missing something, x(-1) a the first lag of x can appear only in list creating or inside a coomand nulldata 100 x = normal() list li = x(-1) ols x(-1) 0 It seems function scalar x(scalar arg) return arg end function So, x(-1) -> -1 This function can not appear while creating lists, Neither is possible to use such function inside a command xlist I think it is possible to force tokenizer to distinguish Oleh

I fear, this can introduce a new mess I think there should be unique separator, e. g. pkg_name::fun_name, or something of this kind Oleh

On Tue, 23 Oct 2018, Riccardo (Jack) Lucchetti wrote: Oleh originally proposed pkg_name.fun_name. My initial response was just based on the fact that this would currently be illegal. Aside from '.' as decimal point (a context that is easily distinguished), '.' in hansl is reserved for bundle membership. Punctuation characters are scarce, and much in demand for use as operators and other syntactic elements. It's true, if you double up such a character, as in "::", you get something that is not acceptable in general, and so could be given a special syntactical import. Then we would have to distinguish between "valid identifier for hansl object in general" and "valid identifier for a function inside a package". Not impossible but an extra layer of complication. Oleh says that my suggestion -- namely, "pkgname_funname" -- could "introduce a new mess". I don't see that. Since underscore is accepted in all hansl identifiers my suggestion does not distinguish with 100% confidence between a name given to a function within a package and a name that happens to be identical in both components and copula, given to some "random" user-function. But the confidence is surely not far off 100%, if the package has a reasonably specific name. And whatever the collision probability, it would certainly be reduced, never increased, if package-writers were to follow a recommendation to prepend "<pkgname>_" to their function names. Allin

On Wed, 24 Oct 2018, Riccardo (Jack) Lucchetti wrote: Good point; noted. Allin

On Wed, 24 Oct 2018, oleg_komashko(a)ukr.net wrote: That's already answered. It will _not_ cause a problem unless your database contains a series named "lagreg", of which you want to take lags using the "series_name(<lag-spec>)" syntax. That (lag) syntax long predates the possibility of user-defined functions in hansl. So far as I know this sort of collision has never been a practical problem to date, but it's not very satisfactory that it's possible at all. So we're trying to figure out the best way of preventing it. Rhetorical questions are not particularly helpful to that task. Allin

On Wed, 24 Oct 2018, Sven Schreiber wrote: Helpful thoughts. I like the approach of thinking about what ought to be known by the user/coder at each point, and therefore what might be an "honestly occurring" ambiguity (versus what could only arise from willful perversity)! I'll think about this some more... Allin