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.?