On Sat, 24 Nov 2018, Sven Schreiber wrote:
Am 24.11.18 um 09:29 schrieb Riccardo (Jack) Lucchetti:
> 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.
I, too, think that it's OK. In principle we could offer some kind of promise
which name pattern will never be used for a built-in function and thus will
be safe forever, but it's probably overkill.
As I mentioned in response to Marcin, I believe we can offer such a
promise: built-in functions will not have an underscore in their
However, I think we should check against all existing function
packages whenever a new built-in is added.
>> * Function packages: Up till now the situation has not been
>> 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.
I don't really see the need for the exception for private functions. Since
gretl doesn't have overloading of functions and such, couldn't the rule
simply be "you mustn't use names of built-in functions, period"? It seems
me that this isn't too much to ask for package authors. Is there currently a
"You mustn't use names of built-in functions, period" is fine
contemporaneously (if that's a word).
But I'm thinking of the case where a package writer has defined a
private function "foo" and then at some later date "foo" is added as
a built-in. This is unlikely to happen often (and it should never
happen if Marcin's rule is followed), but if it does happen I think
it's reasonable that the existing private function is still accepted
(with a warning). This will not trip up package users, since of
course private functions are not accessible by them.
It's possible that a new built-in provides the functionality of an
existing package-private function of the same name, but more
efficiently ("atan2" came close). So we (meaning both package
writers and gretl developers) should pay attention to any namespace
warnings. (Well, actually we should pay attention regardless of
name-collisions and warnings -- it's always good to replace a less
efficient implementation with a more efficient one -- but I think we
are doing that already, in the context of package moderation.)