[Gretl-devel] built-in functions and namespace issues

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