8:57 p.m.
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
8:29 a.m.
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(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
9:07 a.m.
(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
24 листопада 2018, 10:29:13, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
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(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
3:53 p.m.
On Sat, 24 Nov 2018, oleg_komashko(a)ukr.net wrote:
Also, now we can do 'open file' instead of open file.gdt
That's a shortcut that has been available for a long time.
For example, 'open poisson' crashed gretl
?? Can you give some context, please. It works as expected here.
Allin
6:47 p.m.
Strangely,
It means, I misspecified the cause of
crash, may be that's because
opened all files from Greenme
in one script to run arimas
Oleh
24 листопада 2018, 17:54:24, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Sat, 24 Nov 2018, oleg_komashko(a)ukr.net wrote:
Also, now we can do 'open file' instead of open file.gdt
That's a shortcut that has been available for a long time.
For example, 'open poisson' crashed gretl
?? Can you give some context, please. It works as expected here.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
12:29 p.m.
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.
> * 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 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 to me that this isn't too much to ask for package authors. Is
there currently a precedent?
cheers,
sven
12:54 p.m.
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.
Marcin
--
Marcin Błażejowski
4:24 p.m.
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
7:56 p.m.
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
names.
However, I think we should check against all existing function
packages whenever a new built-in is added.
Agreed.
>> * 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 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
to
me that this isn't too much to ask for package authors. Is there currently a
precedent?
"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.)
Allin
4:31 p.m.
Am 24.11.18 um 20:56 schrieb Allin Cottrell:
On Sat, 24 Nov 2018, Sven Schreiber wrote:
> 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 names.
OK.
> 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 to me that this isn't too much to ask for package
> authors.
"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 is a privileged treatment of private functions in packages, and
it's very nice of you. However, I don't see the fundamental difference
to a non-packaged function that somebody uses locally, where we agree
that people will be required to change those names if a new built-in
comes along. So I advocate the following:
- Built-in functions are taboo, period.
- Before releasing a new gretl version, or even before adding the new
built-in to git, we screen all function packages for a clash. If there
is one, we either require the package author(s) to change the respective
private function name, or perhaps in certain circumstances we change the
new built-in's name.
But I'm also fine with the current solution, but in a sense it's
probably more error-prone on gretl's side.
cheers,
sven
9:05 a.m.
On Sun, 25 Nov 2018, Sven Schreiber wrote:
This is a privileged treatment of private functions in packages, and
it's
very nice of you. However, I don't see the fundamental difference to a
non-packaged function that somebody uses locally, where we agree that people
will be required to change those names if a new built-in comes along. So I
advocate the following:
- Built-in functions are taboo, period.
- Before releasing a new gretl version, or even before adding the new
built-in to git, we screen all function packages for a clash. If there is
one, we either require the package author(s) to change the respective private
function name, or perhaps in certain circumstances we change the new
built-in's name.
But I'm also fine with the current solution, but in a sense it's probably
more error-prone on gretl's side.
I'm 100% with Sven on this.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
10:40 a.m.
New subject: built-in functions and namespace issues: reserved words
open data3-9.gdt
Now can not be opened since
it contains a series named 'return'
Interestingly, what problems it caused
before prohibition?
For example, I can use some R xml package,
open it in R not using gretl, rename and
save as .gdt
Is this way suitable for most users?
Oleh
23 листопада 2018, 22:57:38, від "Allin Cottrell" <cottrell(a)wfu.edu>:
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
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
4:13 p.m.
New subject: built-in functions and namespace issues: reserved words
On Sat, 24 Nov 2018, oleg_komashko(a)ukr.net wrote:
open data3-9.gdt
Now can not be opened since
it contains a series named 'return'
Interestingly, what problems it caused
before prohibition?
Actually it seems that didn't cause problems before; the new behaviour
is probably too restrictive. I'll revise that.
For example, I can use some R xml package,
open it in R not using gretl, rename and
save as .gdt
Is this way suitable for most users?
No, I'm sure it's not! But in case you have a gdt file that gretl
won't open it can generally be fixed in any decent text editor. Still
not suitable for most users, of course.
Allin
6:43 p.m.
New subject: built-in functions and namespace issues: reserved words
Actually I did so,
nyce from Koops also contains return
but it has starange recodimg
I opened it in older gretl and renamed
Oleh
24 листопада 2018, 18:13:50, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Sat, 24 Nov 2018, oleg_komashko(a)ukr.net wrote:
open data3-9.gdt
Now can not be opened since
it contains a series named 'return'
Interestingly, what problems it caused
before prohibition?
Actually it seems that didn't cause problems before; the new behaviour
is probably too restrictive. I'll revise that.
For example, I can use some R xml package,
open it in R not using gretl, rename and
save as .gdt
Is this way suitable for most users?
No, I'm sure it's not! But in case you have a gdt file that gretl
won't open it can generally be fixed in any decent text editor. Still
not suitable for most users, of course.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
1979
days inactive
1982
days old
13 comments
5 participants
participants (5)
-
Allin Cottrell -
Marcin Błażejowski -
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti -
Sven Schreiber