[Rd] `*tmp*`

Peter Meilstrup peter.meilstrup at gmail.com
Fri Aug 15 20:05:19 CEST 2014


AFAIK there is not supposed to be any user level code that depends on the existence of *tmp*, but there are knock-on effects (evaluating code in a locked environment can succeed with byte code and fail with the interpreter, for instance)

Peter

> On Aug 14, 2014, at 14:35, Michael Haupt <michael.haupt at oracle.com> wrote:
> 
> Hi Luke,
> 
>> Am 14.08.2014 um 12:08 schrieb luke-tierney at uiowa.edu:
>> This is a consequence of the tricks the interpreter implementation
>> currently plays to do complex assignments. Compiled code works
>> differently:
>> 
>>> library(compiler)
>>> cmpfun(function() {
>> +            x<-c(1,2)
>> +    x[1]<-42
>> +    `*tmp*`[1]<-7 # I would expect this one to fail
>> + })()
>> Error in cmpfun(function() { : object '*tmp*' not found
> 
> aha, thank you very much! So the behaviour of the AST and bytecode interpreters differ. Which one is authoritative? Can I cherry-pick? (I'll pick the bytecode interpreter's version if I may.)
> 
> Is there actually any code out there that *uses* `*tmp*` and would hence break if the bytecode interpreter was used? Is it encouraged to not directly access `*tmp*`?
> 
> I'm asking all these questions because, in FastR, we're currently quite closely mirroring the AST interpreter's behaviour for complex assignments - if this is not an absolute must-have, I'd be very happy about being able to apply a much leaner implementation instead.
> 
> Best,
> 
> Michael
> 
> -- 
> Dr. Michael Haupt
> Principal Member of Technical Staff
> Phone: +49 331 200 7277, Fax: +49 331 200 7561
> Oracle Labs
> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list