4:56 p.m.
[moving over to gretl-devel, where I probably should have started this
anyway]
Am 21.01.2011 17:39, schrieb Riccardo (Jack) Lucchetti:
On Fri, 21 Jan 2011, Sven Schreiber wrote:
A few remarks:
* We don't have "clear", which would probably be nice, but we have
"nulldata": "nulldata 2" probably does what you want.
Yeah, except that it also clears the dataset, which is maybe not what I
want. Maybe 'nulldata' could be merged into a new 'clear' somehow?
clear --data # like nulldata --preserve
clear --all # like nulldata
clear # only clear variables like matrices, scalars, bundles,
strings, lists(?)...
???
(This is clearly a suggestion I only dare making in the context of the
pre-2.0 cycle, in general I would find it too disruptive.)
* The relative merits of strong typing vs weak typing will always be an
object for discussion. I personally prefer strong typing, but I concede
that in a world where the most popular matrix-oriented languages are
weakly-typed perhaps you have a point.
My point was not against strong typing in this context (although it
helped to trigger the error here, of course). It would be fine if in the
scope of the script the type of temp were fixed (strong typing). I'm
pointing out the problems of the fact that the scope of the variable
temp is automatically global, i.e. extends beyond the current script.
* I would guess that if you have scripts that are meant to be run one
after another with little or no editing, perhaps you ought to use
functions and keep the usage of global variables at a minimum. Perhaps
bundles may help too.
AFAICS this essentially would imply that *everything* needs to be
wrapped inside functions. I don't think that would be good. Note I
didn't *want* to make thiese variables global, but with gretl's current
behavior I don't have a choice (if I don't want to wrap everything in a
function); so I view your statement "keep global variables at a minimum"
as supporting my point!
thanks,
sven
5:46 p.m.
New subject: [Gretl-users] variable types in different scripts
On Sat, 22 Jan 2011, Sven Schreiber wrote:
[moving over to gretl-devel, where I probably should have started
this
anyway]
Am 21.01.2011 17:39, schrieb Riccardo (Jack) Lucchetti:
> On Fri, 21 Jan 2011, Sven Schreiber wrote:
>
> A few remarks:
>
> * We don't have "clear", which would probably be nice, but we have
> "nulldata": "nulldata 2" probably does what you want.
Yeah, except that it also clears the dataset, which is maybe not what I
want. Maybe 'nulldata' could be merged into a new 'clear' somehow?
clear --data # like nulldata --preserve
clear --all # like nulldata
clear # only clear variables like matrices, scalars, bundles,
strings, lists(?)...
???
(This is clearly a suggestion I only dare making in the context of the
pre-2.0 cycle, in general I would find it too disruptive.)
For the sake of completeness, I wouldn't be against a "clear" command to
get rid of selected categories of items. Maybe we could spice up the
"delete" command a bit, like for example adding a --matrix option to
delete matrices only, etc.
> * The relative merits of strong typing vs weak typing will always
be an
> object for discussion. I personally prefer strong typing, but I concede
> that in a world where the most popular matrix-oriented languages are
> weakly-typed perhaps you have a point.
My point was not against strong typing in this context (although it
helped to trigger the error here, of course). It would be fine if in the
scope of the script the type of temp were fixed (strong typing). I'm
pointing out the problems of the fact that the scope of the variable
temp is automatically global, i.e. extends beyond the current script.
No, sorry, I don't like this at all. The "include" command must leave
objects alone. On a somewhat related subject: do we still want to keep
both "include" and "run" for 2.0?
> * I would guess that if you have scripts that are meant to be run
one
> after another with little or no editing, perhaps you ought to use
> functions and keep the usage of global variables at a minimum. Perhaps
> bundles may help too.
AFAICS this essentially would imply that *everything* needs to be
wrapped inside functions. I don't think that would be good. Note I
didn't *want* to make thiese variables global, but with gretl's current
behavior I don't have a choice (if I don't want to wrap everything in a
function); so I view your statement "keep global variables at a minimum"
as supporting my point!
Not really. If you want to use something as a black box, yes. But
otherwise, I don't see why. For example: I have a fairly large project
open, a paper my co-authors and I have been working on for quite a long
time. I have a script, called prepare_data, that sets everything up for
estimation, testing etcetera. The dataset gets opened there, basic
transformation are done there, global scalars/matrices/lists are defined
there. Its purpose is precisely to define stuff that is meant to remain
global for the whole session, so that I can have as many scripts as I need
that start with "include prepare_data.inp" and proceed from there.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
6:52 p.m.
New subject: [Gretl-users] variable types in different scripts
Am 22.01.2011 18:46, schrieb Riccardo (Jack) Lucchetti:
On Sat, 22 Jan 2011, Sven Schreiber wrote:
For the sake of completeness, I wouldn't be against a "clear" command to
get rid of selected categories of items. Maybe we could spice up the
"delete" command a bit, like for example adding a --matrix option to
delete matrices only, etc.
yes, this sounds good too -- but to be clear, this was meant as a
workaround or second-best solution to the variable scope thing, not as a
main thing to push
>
> My point was not against strong typing in this context (although it
> helped to trigger the error here, of course). It would be fine if in the
> scope of the script the type of temp were fixed (strong typing). I'm
> pointing out the problems of the fact that the scope of the variable
> temp is automatically global, i.e. extends beyond the current script.
No, sorry, I don't like this at all. The "include" command must leave
objects alone. On a somewhat related subject: do we still want to keep
both "include" and "run" for 2.0?
when I wrote "current script" I meant the same thing as before, namely
the current top-level script which is executed; and this top-level scope
would still be in effect when including child scripts, functions etc.
>
> AFAICS this essentially would imply that *everything* needs to be
> wrapped inside functions. I don't think that would be good. Note I
> didn't *want* to make thiese variables global, but with gretl's current
> behavior I don't have a choice (if I don't want to wrap everything in a
> function); so I view your statement "keep global variables at a minimum"
> as supporting my point!
Not really. If you want to use something as a black box, yes.
IMHO it's absolutely clear that sometimes you want to have a black box.
You said it yourself, only that you then say "well, use functions".
Another solution would be to require script authors to do the garbage
collection themselves, i.e. issue the needed 'delete' statements. I was
arguing for a kind of automatic garbage collection by limiting the scope
of variables, maybe because I'm lazy. Also, that would probably require
the declaration of explicitly global variables. Perhaps the
disadvantages of those changes are too serious. Fair enough, I could
understand that. But it should be acknowledged that it is a real
limitation of gretl to have only global variables (apart from the
function scope), not to turn that around into a feature.
cheers,
sven
7:19 p.m.
New subject: [Gretl-users] variable types in different scripts
On Sat, 22 Jan 2011, Sven Schreiber wrote:
> Not really. If you want to use something as a black box, yes.
IMHO it's absolutely clear that sometimes you want to have a black box.
You said it yourself, only that you then say "well, use functions".
And I'll say it again, and again, and again.
Another solution would be to require script authors to do the
garbage
collection themselves, i.e. issue the needed 'delete' statements. I was
arguing for a kind of automatic garbage collection by limiting the scope
of variables, maybe because I'm lazy.
I agree on your analysis ;-)
Also, that would probably require the declaration of explicitly
global
variables. Perhaps the disadvantages of those changes are too serious.
Fair enough, I could understand that. But it should be acknowledged that
it is a real limitation of gretl to have only global variables (apart
from the function scope), not to turn that around into a feature.
I will _not_ acknowledge that's a limitation. No, sir. It's a feature,
which encourages clean script writing. In a _compiled_ language (with
header files etcetera) I can see the scope of file-local variables. In an
_interpreted_ language, hmm...
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
5083
days inactive
5083
days old
3 comments
2 participants
participants (2)
-
Riccardo (Jack) Lucchetti -
Sven Schreiber