[Rd] R GUI API: suggestion for R function to put in there?
Philippe Grosjean
Philippe.Grosjean at umh.ac.be
Sun Oct 29 17:54:51 CET 2006
Well, following a discussion with Duncan Murdoch, where he suggests me
to rewrite my requests, here it is.
Just a couple of problems I found difficult to solve, as a writer of R
GUIs, and for which I would be very happy to get a R function (plus
rationates):
- To know if an evaluation returns invisibly or not. This is discussed
in a previous thread. We now have withVisible().
- To know if some R code is complete or is continued to the next line.
The following trick was suggested by Peter Dalgaard once, but it is
fragile because it depends on the way R prints errors, and that may
change in the future:
isLineComplete <- function(x) {
# x is a character string vector with R code
# The function determines if the parser is satisfied with it
# or it needs more input (code is continued at the next line)
# First parse code
con <- textConnection(x)
expr <- try(parse(con), silent = TRUE)
close(con)
# Determine if this code is correctly parsed
if (inherits(expr, "try-error")) {
results <- expr
# Determine if it is an incomplete line
if (length(grep("\n2:", results)) == 1) return(FALSE)
}
# Note: here, we return TRUE also if the code is wrong
# but one could enhance the function to return something
# else in case of wrong R code
return(TRUE)
}
> isLineComplete("ls()")
[1] TRUE
> isLineComplete("ls(")
[1] FALSE
> isLineComplete("ls())")
[1] TRUE
- To execute R code contained in a string and return the result of this
evaluation in a string (including presentation of error messages and
warnings) exactly as if this was entered at the prompt. Duncan Murdoch
is against such a kind of function (he says a GUI should not substitute
to the R interpreter, and it should manage and present errors or
warnings in a better way than the teletype approach of the command
line). However, there are occasions where we would like to embed a
little R interpreter in a GUI. R Commander and Tinn-R are two good
examples. Also, I advocate for a R GUI that is a layer on top of the R
Console, but ultimately shows to the user (1) what is the equivalent R
code he should type at the prompt, and (2) what does R replies if this
code is issued at the prompt. That way, the GUI is just a convenient way
to learn R, and to get a smooth move to the intimidating command line.
In this context a kind of 'execute("some R code")' function should be
fine (and I see a couple of additional usages for this too).
- In the same idea, to write a similar function, but that returns a list
of strings, each string being flagged as 'output', 'warning' or 'error'.
The succession should correspond to the evaluation (this is especially
tricky for warning messages, due to the complex way R handles those
warning message.
- To know which objects were changed since a given date, or during last
call. This should require a time flag on the variable that contains this
object. One particular application is an object explorer that could
update information quickly if it could query only those objects that
have changed since last process. This topic has already been discussed a
couple of times, and no convincing solution has emerged (technical
problems), it seems... but it is worth to continue thinking about it.
- To know if R is currently processing something in another event loop.
Since R was designed initially to work with a single event loop, this
was obviously useless. Now that we can use separate event loops for,
let's say, command issued at the prompt, and do some other jobs with the
embedded Tcl (tcltk package), for instance, it could be useful to know
the state of R for the respective event loops. For instance, I would
like to know if R is processing some code issued at the prompt, from an
interface written in Tcl (like svSockets, for instance, or the mini-web
server built in Rpad, for another example).
This is just a couple of suggestions that would make the life of R GUI
writers a little bit easier (at least mine). Now, I don't want to enter
in endless discussion if something is useful or not,... but if someone
has the solution for one of these problems, or is ready to write an R
function to provide such functionalities, i would be very happy.
Best,
Philippe Grosjean
More information about the R-devel
mailing list