[Gretl-devel] update on gretl functions and lists

[Sven Schreiber]

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 at wfu.edu>
> An: r.lucchetti at univpm.it, Gretl development <gretl-devel at 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