[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