Re: [Gretl-devel] update on gretl functions and lists
On Tue, 22 Jul 2008, Riccardo (Jack) Lucchetti wrote:
On Tue, 22 Jul 2008, Allin Cottrell wrote:
> Here is a newly revised version of the cubes function that I used
> for illustration previously.
>
> function make_cubes (list xlist)
> list retlist = null
> loop foreach i xlist --quiet
> series $i3 = xlist.$i^3
> list retlist = retlist $i3
> end loop
> return list retlist
> end function
This is a really, really good thing. Thanks a lot for taking
care of this.
And thanks for speaking up about my previous attempt at a
solution, which I agree was really not good enough!
If all goes well, IMO we should make the switch to the new
scheme and give people some time to fix the
backward-incompatible scripts (which I anticipate will be LOTS).
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?
For the present, though, I wonder if the following "wretched
compromise" might work. Right now, in CVS, "protection" of list
arguments is governed by a compile-time flag. We're agreed (I
think) that this should become the norm before too long. But in
the meantime (gretl 1.7.6) we could turn it into a "set" variable.
The question would then be: what's the default value?
Well, let's first note a couple of points:
* There's no way that any functions containing the
"listname.varname" locution will run on gretl <= 1.7.5.
* I envisage that gretl 1.7.6 will _support_ the
"listname.varname" locution, regardless of what we decide about
the default value of protect_lists.
Given the above points:
* If the default is 0/false (list arguments not protected), then
we don't break any existing scripts. People are free to (and we
can encourage them to) write functions that are "list-safe".
Such functions won't run on gretl <= 1.7.5, but that's a given.
* If the default is 1/true, we do break (some, maybe lots of)
existing scripts containing functions. The breakage can be
"repaired" by a simple set command, but only if gretl 1.7.6 is
used.
I think the trade-off here favours making 0/false the default.
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.
Allin.