Re: [Rd] `*tmp*`
On Thu, 14 Aug 2014, Michael Haupt wrote: Hello, given that `*tmp*` is removed after a replacement, how can code like this work? Is there some special handling for a variable named `*tmp*` when it comes to make element assignments? x<-c(1,2) x[1]<-42 `*tmp*`[1]<-7 # I would expect this one to fail `*tmp*` Error: object '*tmp*' not found 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 luke Confused greetings, Michael -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] `*tmp*`
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
Re: [Rd] `*tmp*`
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 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
Re: [Rd] `*tmp*`
On Thu, 14 Aug 2014, Michael Haupt 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*`? There should not be -- the language manual I believe had language that suggests that this is an implementation detail that should not be relied upon. 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. The compiler tries to stay very close to the interpreter. The main departures are (a) assuming certain bindings are not changeable, based on optimization level, and (b) cleaning up semantics in cases where the interpreter does things to either improve performance or simplify implementation that are not really desirable. These departures should be described in the noweb file in the compielr package. (b) applies to the complex assignment mechanism. The use of *tmp* was convenient but unclean. The byte code interpreter has a stack that is can use for storing the intermediate stuff that *tmp* is used for in the interpreter. It would be possible in priciple to make the match the compiler behavior. I don't know how hard it would be to do so without a performance hit (or maybe with a gain) -- I just haven't looked. The complex assignment mechanism is a very tricky bit of code, and there are a lot of hidden pitfalls and a number of hidden assumptions needed for it to work reliable, especially with respect to avoiding duplication of LHS values, but duplicating when necessary. Another know issue is that in nested complex assignments the index expressions will get evaluated twice, which means expressions with side effects (e.g. ones that generate a random number and update a seed) don't do what users expect (they _do_ do what the language manual says, since it implies the multiple evaluation). Addressing this is hard given the lazy evaluation/nonstandard eval combination, but it would be nice to see if we can do better. I keep meaning to write up notes on my current understanding of the assignment mechanism. I may get to it in a month or two; if i do it will appear in the R-dev-web tree. Best, luke Best, Michael -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel