I'm working on a package that implements a REPL. A typical interaction with
the package might look like:
> launch_REPL()REPL> 1 + 1[1] 2REPL> QDo you wish to save results? [y/n]REPL>
> ygoodbye ...>
This is very similar to what happens when in `browser()`: the REPL evaluates
arbitrary R user expressions and offers some additional commands.
In order to implement functionality required for the REPL I must trace some
functions in the base package. The trace is removed `on.exit()` from the REPL,
so the functions are only modified while the `launch_REPL` function is
evaluating. Unfortunately this is against the letter of the law (as per CRAN
policy):
> A package must not tamper with the code already loaded into R: anyattempt to
> change code in the standard and recommended packages whichship with R is
> prohibited.
Is there any chance that this very limited (only during my function evaluation)
modification of base functions with `trace` could be considered to meet the
spirit of the law, if not the letter? Package users would be duly notified
this is happening.
Regards,
Brodie Gaslam.
PS: More details for those who care: the REPL among other things implements an
environment that has for parent `as.environment(2)` so that objects in the
global environment are not visible while in the REPL, but otherwise the full
search path is. Anytime the search path changes I need to update the REPL
environment to re-point to `as.environment(2)`, which means I need to know when
the search path changes. I do this by tracing `library`/`attach`/`detach` and
triggering a side effect that updates the REPL environment parent any time
those are called. The search path itself is untouched. I cannot just parse
user expressions searching for those functions as the user can use any
arbitrary expressions, including sourcing files that contain the `library`,
etc. calls.
[[alternative HTML version deleted]]
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
