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

On Fri, 23 Nov 2018, Allin Cottrell wrote: > * 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. I don't think it should; IMO this is a very sane policy, and we should commit to it indefinitely, for the sake of consistency. The most we can do is give the user an error message that is as explicit as conspicuous as possible, so that fixing the script becomes easy.

> * 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). I have uneasy feelings about (2), though I couldn't put my finger precisely on why.