I'm resuming, after some investigation and updates to the libgretl 
code, a discussion that took place not so long ago; see the thread 
started by 
http://lists.wfu.edu/pipermail/gretl-devel/2018-October/009146.html

The question I'm taking up is: What happens if you (try to) define 
an object of some sort with a name that collides with that of a 
built-in function? Here are some answers:

* We allow creation of variables (series, matrices, scalars, etc.) 
that have the same name as built-in functions. For the most part 
this should not lead to ambiguity, since a correctly used function 
name must be followed directly by '(' while this character can only 
follow a variable name in the case of lags of a series. In light of 
the possible ambiguity in the case of series we now issue a warning 
(and we try to figure out what's probably intended).

* When a function definition is encountered in a regular hansl 
script, we flag an error if it uses the same name as a built-in 
function. This has the implication that scripts that run at time t 
may fail at time t+k if in the meantime a built-in function has been 
added to libgretl, with a name equal to the name of a function in 
the script. Maybe this should be revisited at some point.

* Function packages: Up till now the situation has not been very 
secure. My testing indicates there have been no collisions to date, 
but I guess package writers and libgretl coders must have been 
careful and/or lucky -- since packaged functions have been exempt 
from namespace checks (other than for inter-package collisions). If 
a collision with a built-in function had occurred, the result would 
have been that the built-in took priority and the packaged function 
was ignored. In today's git that is changed as follows:

(1) We reject public packaged functions that collide with built-ins 
and post an error message.

(2) We'll accept private packaged functions that collide with 
built-ins, and give the packaged function priority in the context of 
functions that belong to the package (only).

Since testing of all current function packages is part of the 
routine prior to a release, it should be straightforward to detect 
any problems arising under point (1).

Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel