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