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]]
