On Sat, 24 Nov 2018, Marcin Błażejowski wrote:
On 24.11.2018 13:29, 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. Functions
> aren't added _that_ often. However, I think we should check against
> all existing function packages whenever a new built-in is added.
And here I remind some conversation we all had at Bilbao about name
spaces for (at least public) functions in packages. We stated that name
space could/should base on the abbreviation of the name of the package.
Probably it's not feasible now, but if we could encourage the autors to
set the name space of their funcitions according this rule we are safe.
I know - backward incompatibility, but IMO the it worth to be done.
I'm not sure about making that policy mandatory, but I agree it's good
advice to package authors.
May be worth noting that no built-in function has an underscore in its
name, and I think we can reasonably commit to keeping things that way.
So, for example, using a three-letter prefix with underscore would
guarantee no collision with a built-in.
Allin