[Gretl-devel] @-substitution and printf

This follows on the gretl-users thread starting with http://lists.wfu.edu/pipermail/gretl-users/2012-December/008282.html where Artur Tarassow raised a question about commands such as printf "%.3f\n", m1ATfoo where "foo" is the name of a pre-defined string variable (and where I've written "AT" in place of the at-sign to try to avoid getting mangled by pipermail). Artur's intent was that gretl should interpret the argument (after substitution) as the name of scalar variable, but this wasn't working, because the usual at-sign substitution wasn't being done for the arguments to printf. I then commented that it would seem more consistent to do string substitution in that context, and I made a change in CVS that enabled commands of this sort. However, I also mentioned that I thought there had been a reason, at some point in the past, for _not_ doing such substitution, and now I've rediscovered it. The reason is not compelling in itself, but ignoring it does introduce an element of backward incompatibility. Take a sequence like this: string tmp = "hello" printf "%10s\n", ATtmp # Exhibit A (where again I've used "AT" to prevent mangling). Should this work? Arguably it should not, since after substitution what we have as an argument is "hello", _without_ the double quotes, and this is neither a string literal nor the name of a string variable (unless it happens that a string named "hello" was defined earlier). Correct variants of the above would be printf "%10s\n", tmp or (clumsy but OK) printf "%10s\n", "ATtmp" The only problem is that Exhibit A used to work, and I've found an instance among the contributed function packages. It worked on condition that we (a) did not do ordinary string subst for the printf arguments, but then (b) did a special fix-up when the arguments were processed through the "genr" mechanism. This was ugly hack, supporting something that really shouldn't have worked, and I'm not recommending we re-establish it. I'm just pointing out that there's a backward compatibility issue here: if we keep the new code we'll have to advertise the change properly. Allin