[Gretl-devel] Backward compatibility

Allin Cottrell cottrell at wfu.edu
Mon Nov 5 22:17:47 EST 2007


On Mon, 5 Nov 2007, Riccardo (Jack) Lucchetti wrote:

> On Mon, 5 Nov 2007, Ignacio Diaz-Emparanza wrote:
> 
> > I suppose you remember my message about building a function 
> > with one input series and several output series, that I wanted 
> > to be named accordingly to the input series (see 
> > http://lists.wfu.edu/pipermail/gretl-users/2007-June/001722.html 
> > ).
> > 
> > I needed a "string" parameter in a function, but given that 
> > string parameters are not allowed in a function I solved my 
> > problem using an external string inside my function (I know 
> > this is not very smart but ... ).
> 
> I agree wholeheartedly on the fact that it should be possible to 
> use strings as function arguments. Every time I tried to write 
> complex user-level sets of functions, this limitation was quite 
> painful.

Granted, this should be possible.

> The issue is not easy, though. From my understanding of the 
> code, it works more or less like this (Allin, please correct me 
> where I'm wrong -- it could be ALL wrong): every user-defined 
> string is contained in a static array called saved_strings; as 
> such, no matter how deep function nesting is, all strings are 
> potentially accessible. However, we keep track of the level at 
> which each string is defined, so that the string is in fact 
> usable only at that level.

Yes, but keeping track of levels is new -- that's why Ignacio's 
function stopped working.

> We could work around Ignacio's problem in more than one way:
> 
> 1) let strings be visible everywhere. Definitely dangerous.

Used to be the case.  Too ramshackle.

> 4) enable GRETL_TYPE_STRING as a function argument and store a 
> copy of the string in the global array, only marked at a 
> different level. The copy should be destroyed on function exit. 

Yes, IMO this is the only sane way to go.  I've made a start on 
it.  The modifications to the existing code are not too severe.
I'll test tomorrow than make a snapshot available.

Allin.


More information about the Gretl-devel mailing list