Re: [Gretl-devel] issue with model table (since 1.9.0?)
Am 30.06.2010 00:02, schrieb Allin Cottrell:
On Tue, 29 Jun 2010, Sven Schreiber wrote:
> a model table assignment inside a function doesn't work anymore
> (where "anymore" means with recent cvs gretl and it used to work three
> months ago -- I just checked on 1.9.0 on Windows and get the same error,
> so maybe it was introduced between 1.8.7 and 1.9.0)
>
> What I mean is something like this:
>
> function void check(...)
> mymodel <- tsls ...
> end function
>
> check()
>
> gives an error "unknown command mymodel <- ..."
>
> Or is this not supposed to work (anymore) in a function, I don't
> remember?
Hmm, I think it's not supposed to work inside a function, on the
grounds that it breaks encapsulation.
Well I think I have repeatedly used this type of behavior of functions
(modifying the session icon view etc.) as an argument in our mailing
list discussions that encapsulation was never complete (by design, I
thought). Another favorite example of mine is the way members of named
lists are returned back to outer scope and possibly overwrite other series.
So in principle I'm all for encapsulation of the function scope, but I
have learned to accept that gretl has some exceptions to this rule for
convenience reasons.
But if it worked earlier
then either the change should be reverted or it should go into the
log of backward-incompatible changes.
Yes -- but while I'm >90% sure that it worked (because I took a saved
script that used to give me results and simply tried to run it again)
there's always the possibility that I screwed up so maybe this should be
tested on 1.8.7 before taking action.
I wonder... might it be worth introducing for gretl 2.0 a "macro"
construct, alongside the (by now relatively heavy-duty) function
construct? I have in mind a very relaxed variant of a function,
which has access to everything at caller level. It could take
arguments and return stuff if wanted, but could accomplish useful
work without doing that.
I haven't thought this through fully but I'm thinking that it
wouldn't be very difficult to implement, and might make life
easier for people who are not writing function packages but just
trying to make a script more structured/modular.
Hm, I'm sceptical. OTOH, doesn't the 'run' command already do something
similar? I mean it executes gretl code right where 'run' appears, so
that's something like that, no? (Apart from the argument passing, but
there's an obvious way to emulate that right before calling 'run'.)
Another (and probably easier) alternative might be to make a
distinction between functions that are part of a package and those
that are not, and to relax some restrictions (e.g. on adding stuff
to the model table) for the latter sort.
yeah, taking up the previous observation that encapsulation is not 100%
right now: maybe explicitly expand this route and ditch the goal of
encapsulation. For example, perhaps a solution might be to always allow
functions to *add* something to outer scope. The "prime directive" might
be to prevent dataloss, so deletion and altering of existing objects
might be forbidden, but not creating new stuff. Of course that's
absolutely not functional programming style and purists will shudder,
but maybe that should be considered anyway -- just a thought.
let's see where this leads us...,
sven