Gretl have a finite number
of foreign interfaces
May be, a decent solution
is in making the use of '@'
foreign language-specific
(or, python-specific)
With R it is a luxurous feature:
it makes transfer of non-series
data very convinient
I'd prefer for changes to be
specific and not to remove this
possibility from foreign R
Oleh
9 лютого 2017, 22:57:19, від "Sven Schreiber" <svetosch(a)gmx.net>:
Hello again,
I am trying to become a forward-looking/rational-expectations/precog bug
reporter... Seriously, here is a worry that is inspired from a trick
that Oleh used in one of his scripts with a 'foreign' block, but that
hasn't actually produced any errors in real life, at least for me.
AFAICS gretl currently applies string substitution with @-tagged
unquoted strings everywhere in the script. So a defined string s="be"
can be injected somewhere by writing @s. This feature can be used to
transfer some string values from the gretl environment to the 'foreign'
environment.
However, this might become a problem when the @-character has another
syntactic meaning in the foreign language. For example in Python it
starts a so-called decorator.
Theoretical example without practical meaning:
string p = "heyho"
foreign language=Python
@property
def mypyfunc(...): ...
end foreign
The way I see it, gretl would turn the decorator line "@property" into
"heyhoroperty" which of course breaks the Python code.
If that assessment is correct, not sure what the best solution would be.
As I said, the behavior has been used intentionally by some.
Comments welcome,
Sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel