On Sun, 16 Jun 2024, Sven Schreiber wrote:
Am 16.06.2024 um 16:29 schrieb Allin Cottrell:
> On Sun, 16 Jun 2024, Sven Schreiber wrote:
>
>> Am 16.06.2024 um 15:00 schrieb Cottrell, Allin:
>>> "bL" is the name of a function, not a bundle, so "bL.L"
is a nonsense
>>> string. Is the following what you meant to write?
>>
>> Whoops, this happened when trying to make the example as minimal as
>> possible.
>>
>> So here's a new variation of what I'm trying to show:
>> ...
> b.L is reported as a matrix at caller level because inside a bundle it's
> just a vector of (putative) series ID numbers. If it turns out that there
> are in fact series with those ID numbers at caller level, the vector can be
> extracted as a list. But that's not the case here: the series "x"
inside
> the function has ID 5 (the next number after IDE with ID 4 in the denmark
> dataset), and there's no series with that ID at caller level.
Yep, I basically know all that. I'm also not exactly sure what I'd prefer in
this case. But the point is that when leaving the function, the list inside
the bundle becomes invalid, but nobody tells the user about this situation.
Instead, you get type changes and other side effects that are only expected
when you really know the internals of gretl. So perhaps what I'm trying to
say is that some warning or error might be useful.
"Doctor, it hurts when I do this." "Well then, don't do that."
I agree this is kinda complicated, but I think you're making it more
complicated than it need be. A function writer who has read the
chapter of the User's Guide on User-defined functions should know
that if you return in a bundle a list that references series that
are local to the function it will be little or no use to the caller:
so don't do it. It's not really a matter of hidden "internals" but
of documented behaviour -- but of course if the documentation isn't
as clear as it should be, that ought to be rectified.
By contrast, here's a case that will work fine. The caller passes as
an argument a list L. The function returns a bundle containing
(presumably among other things) a list that includes just those
members of L that have some definite property. The caller can
extract this from the bundle as a genuine list with no problem,
since none of the series it references are local to the function.
Notice also that when you do 'print b' on the outside scope
after
the function call, gretl says:
bundle b:
L (list)
So gretl itself is also stumbling over this.
The "print" command applied to a bundle just shows the nominal type
of each member, as set when the bundle was populated. Maybe in the
case of series and lists it should say "nominally a {series|list}".
But if a function writer is aware of the rules, such type-ambiguity
should arise only in exceptional cases (e.g. the bundle was created
in a context where a dataset was in place, but now there's no
dataset).
Allin