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.ha...@oracle.com> wrote: > > Hi Luke, > >> Am 14.08.2014 um 12:08 schrieb luke-tier...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel