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.)
Allin:
> 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?
Not the way things are at present. Is your idea that this would
give the ID number of the variable at position i in the list? If
so, I'm not sure how that would be useful.
Allin:
> * 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.
My (not perfectly comfortable) defence of the setup I describe
above would run something like this: when you pass a plain series
(not a series-pointer) to a function, the function can't modify
the series at caller level. The same for matrices and so on. So
lists should conform: you'd need a list-pointer to modify the list
itself. But part of the idea of a list argument is that the
member series are made accessible as such (without any copying of
values). A list is a sort of "pointer to multiple series", which
are therefore modifiable unless marked as const.
(A somewhat analogous issue arises in C programming, where it can
also be confusing -- for example, in the distinction between
"const char *s" and "char const *s".)
Possibly, it would be more intuitive to make list-argument series
const by default -- so that you'd need some sort of "unconst" flag
for a list parameter to indicate that the member series could be
modified. But maybe we should take a sort of inventory here and
see whether the current ability to make changes to list-argument
series is actually used in real-world functions. If nobody is
making use of this, we could just eliminate it.
One further point of clarification: As I see it, the live options
in this respect are (a) the status quo, or (b) make list-argument
series totally unmodifiable within functions by default (with or
without an "unconst" switch to undo this). That is, it would be
very awkward to permit "function-local" changes to such series
that would then be undone on exit.
Allin.