(1) (2) I think, private and public functions should be treated separately:
privates should have priorities: since they do some work is intended
by a writer a new build in should not change this behavior
public: new packages: of course, new functions should
not be created if a name is "colored"
existing packages: I think it is not a good idea to
create flows of backward incompatibility events
If a name of a package function would became "colored"
a possibility of "long syntax" would be helpful:
package|separator|name
I have ran simulation on all gretl/gretl time series
data files: one contains a series i: I was ought
to make changes in one function
Also there were inv and I: there were only warnings,
but I do not understand the text:
It seems. lags(variable) behavior is changed but
text about "variable shadows function"
I looked at good English dictionaries Wrbster ets
to shadow is an active verb
Also, now we can do 'open file' instead of open file.gdt
For example, 'open poisson' crashed gretl
Oleh
My 2 € cents on this:
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. I'm imagining a situation when somebody downloads a
package, copies a function from it to a script, and sees it failing or,
worse still, giving different results. Hmmm.
I realise the practical difficulties implied in any alternative to rule
(2), but still I'm not 100% convinced.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti@univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel