Re: [Gretl-devel] update on gretl functions and lists
-------- Original-Nachricht --------
Datum: Wed, 23 Jul 2008 09:09:41 -0400 (EDT)
Von: Allin Cottrell <cottrell(a)wfu.edu>
An: Gretl development <gretl-devel(a)lists.wfu.edu>
Betreff: Re: [Gretl-devel] update on gretl functions and lists
On Wed, 23 Jul 2008, Sven Schreiber wrote:
> 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.)
I'm not exactly sure what you mean here. We do iterate over
i=1..n at present; that's what plain "i" retrieves. The question,
I think, is what "$i" should get. (Using "$i" at all is optional,
of course; some loops over lists won't need it.)
So would xlist.i work as well, for example in a loop?
> 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.)
I'm not proposing any change to the current situation in this
respect. The situation is:
* If you pass a list to a function, the member series can be
changed (e.g. using "myvar = 0", where myvar is a variable in the
list, or using "xlist.myvar = 0" in the proposed scheme).
Unless, that is, the list argument is marked as "const", in which
case you'll get an error if you try to mess with a list member.
This is in the User's Guide.
* Given a list provided as a function argument, you can can change
the list within a function (e.g. add/delete members), but this
won't affect the list at the caller level -- the original list is
restored on exit. (We could add the facility of passing a
"pointer to list" such that the list could be changed permanently,
but we don't have that at present. If you want to give the
caller a modified list you have to return a list directly.)
I see. But isn't it a bit incoherent (for lack of a better term) to affect the outer
scope when it comes to list members but not when the list itself is involved? (By default,
I mean.) IMHO it would be more intuitive to have a similar default for all arguments
passed to a function. Maybe that would mean that absence of 'const' would imply
that the list itself could be changed, instead of restoring the default.
> > I think the trade-off here favours making 0/false the default.
>
> yes!
Sorry, I got confused and mis-stated the trade-off. Here's a
corrected account; the trade-off is more symmetrical than I
indicated.
well I think I agree with your default choice anyway -- long live backwards compatibility
;-)
> > 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?
Or as soon as we introduce a relevant change (backward- or
forward-incompatible) in CVS?
Sure
-sven