Re: [Gretl-devel] update on gretl functions and lists
Sorry for not participating earlier in this important discussion, I'm currently
semi-offline.
-------- Original-Nachricht --------
Datum: Tue, 22 Jul 2008 16:34:30 -0400 (EDT)
Von: Allin Cottrell <cottrell(a)wfu.edu>
An: r.lucchetti(a)univpm.it, Gretl development <gretl-devel(a)lists.wfu.edu>
Betreff: Re: [Gretl-devel] update on gretl functions and lists
On Tue, 22 Jul 2008, Riccardo (Jack) Lucchetti wrote:
> This is a really, really good thing. Thanks a lot for taking
> care of this.
I have a couple of questions about the proposed solution:
1. Just thinking out loud, not really proposing this, but before the syntax
listname.varname is fixed for the next 10 years or so what about different styles like
listname[varname] or whatever else may make sense? (Compare the syntax with gretl's
way of accessing individual observations in a variable.)
2. What about indexing the list members not by name but by number? For example in a
foreach loop it would be slightly more intuitive to just iterate over the i=1...n instead
of getting the names via $i. (I'm aware this is not a compelling example, but just to
raise the question before it's too late.)
3. I'm not sure I understand whether in your solution the outer scope can be affected
or not. First, would xlist.myvar = 0 work inside a function and would myvar be changed
outside the function? Second, can the structure of xlist itself be changed inside the
function and affect xlilst outside the function? (Think of adding list members.)
4. If gretl performs a computer-memory copy of the list member values in order to pass
them to a function, what about speed issues if lots of data are involved? Or to put it
differently, is it possible with the new solution to somehow force avoidance of the copy?
Just for comparison: For this reason NumPy (numerical Python) passes arrays to functions
without copying (by address would be the term I guess), which is an exception compared to
the standard Python way.
>
> Alternatively, we may keep 1.7.6 with the old behaviour and put
> out a 1.99.0 release with PROTECT_LISTS on. Development would
> then continue on the "unstable" branch. Once everything is
> sorted out, the development version becomes 2.0, to signify that
> old scripts are not guaranteed to run. Of course, if we get into
> the mindset of breaking backward compatibility, we may reflect a
> little on the things we would like to change (I, for one, have a
> few of those).
I'm not averse to starting work on a new branch, to become 2.0,
with more backward-incompatible changes. What changes you have in
mind?
I'm curious what Jack will propose, but reading your function example reminded me that
I find the syntax with respect to $i awkward. For example instead of $i3 I would prefer to
see explicit string concatenation like $i + '3' or so. IMHO it would be easer to
read. I remember that I had similar feelings about the @-macro stuff, @userdir and such.
...
I think the trade-off here favours making 0/false the default.
yes!
I also think that this sort of consideration raises another issue:
we should add an internal constant, with a $-accessor,
representing the gretl version, a.s.a.p. (i.e. in gretl 1.7.6).
Thereafter, function writers will be able to program around
differences between gretl versions, if they so choose.
That would be good, too. BUt I guess that would also mean that in cvs/snapshot versions
the number would have to be increased right after release, no?
thanks,
sven