[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