On Mon, 5 Nov 2007, Allin Cottrell wrote:
> 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.
I tested this a little and it seems that the basic functionality is there
and everything is reasonably solid.
For example, with CVS you can do fancy stuff like
function ha(string s)
x = @s
sprintf res "%g", x
printf "%s = %s\n", @s, @res
return scalar x
set echo off
set messages off
string foo = "3+4"
x = ha(foo)
x = ha("exp(2)")
gretl version 1.6.6.pre2
Copyright Ramu Ramanathan, Allin Cottrell and Riccardo "Jack" Lucchetti
This is free software with ABSOLUTELY NO WARRANTY
Current session: 2007/11/06 10:46
? run strfunc.inp
/home/jack/Prove/gretl_test/strfunc.inp opened OK
? function ha(string s)
? nulldata 2
periodicity: 1, maxobs: 2,
observations range: 1-2
? set echo off
3+4 = 7
exp(2) = 7.38906
This should be enough for the basic needs of user-level function coders.
In due course, however, we will have to provide proper string handling
functions, IMO. The ones that spring to my mind are
where s is a string, n is an integer and c is a character. String
concatenation could conceivably be obtained via a dedicated function, or
by overloading some operator ("+" and "~" are two of the most
candidates). The only non-obvious function in the above list is split();
an example should suffice:
split("bird,dizzy,monk,mingus", ",", 3)
should yield the string "monk". This is not only cool in itself, but, most
importantly, it avoids the need for string arrays. Plus, varname(X) should
be made a proper string function, returning the "label" field of variable
X. Another one of this kind may be vardesc(X), returning the
The only function that can be added with a small effort is strlen(),
because it yields a number. All the others involve heavier work, because
our genr() apparatus needs to be geared so it can handle strings. IMHO, we
should work on this after release.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche