[I cut in this message that becomes very long]
Duncan Murdoch wrote:
[...]
> And also thanks to Gabor bringing it up: and that's really the solution
> to this second problem. If you want to do something unusual and don't
> see a way to do it, ask on R-devel. If the solution you get requires
> undocumented functions calls or other kludges, suggest a clean solution
> to it.
But that's exactly what I am doing!
OK, now the problem formulated in simple terms: I need a R function that
parses and executes one or several lines of R code and returns EXACTLY
the same output (including presentation of errors, warnings, etc.) as if
I issued the same code at the command prompt. Something like:
execute("some R code\nanother line of R code\netc")
The output of execute() would be character strings corresponding to what
is printed at the R console. May be you don't need such function
personally, but I can cite at least two examples where we need it: R
Commander and Tinn-R... and I am sure it could benefit for other R GUIs too.
Now, the best suggestion I can do for this is the awful code below.
Several points to finalize, and as you say, several parts of the code
are subject to problems in future versions of R, because workarounds are
rather fragile against possible future changes in R.
[...]
> The code below looks fragile to me: it depends on the format of the
> error message report. I'm hoping to make syntax errors more informative
> in the next release, and that will probably change the format of the
> reports.
Yes, I know! That is why this code is NOT released to CRAN, and also why
I do NOT propose it as to John Fox or Jose-Claudio Faria as a patch for
R Commander or Tinn-R, respectively. We are precisely discussing the
problem to find better solutions (the R GUI API?). For instance, could
you suggest a better isLineComplete() function? I am pretty sure one
could get something better using C code, which is something I have not
attempted to do.
> More information about an error is available at the C level, but I'm not
> sure how much of that is published in the API.
>
> Now would be a good time to suggest the ideal thing for parse() to
> return, from your point of view. It may not be doable, but if it is,
> and it would work in other situations, there's a chance it will make it
> into 2.5.0.
OK, you have it formulated hereabove.
>>
>> 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
>>
>> - For functions like: xxx.yyy(), it is impossible to know if they are
>> xxx methods for yyy S3 objects, or simply a function called xxx.yyy()
>> without parsing the code, or interrogating R another way.
>
> I think you shouldn't care. You should leave the evaluation of
> expressions up to R.
Ah, ha! Do you mean that the only valid way to make syntax highlighting
of R code is by parsing that code with R? This is too bad that many
excellent syntax highlighting engines around cannot be used then. For
instance, the best I could do, using GeSHi, is materialized in the R
Wiki. You could certainly spot several places where syntax highlighting
of R code is wrong in the Wiki, but it was the best I could do without
parsing the code in R, indeed. This was about three months of work to
get that result.
> R should provide a way for a GUI to evaluate
> something, and should tell the GUI as much as the GUI needs to know to
> operate, but the GUI shouldn't try to be an R interpreter.
Really? An embedded R interpreter is absolutely not needed in a R GUI? I
am afraid I do not agree with this, especially because I thing that a
GUI should only help users to write code: it should display correct R
code and show the user how it works at the command prompt... to
encourage him to switch to the prompt as soon as possible. And that
would certainly benefit from an embedded R interpreter in the GUI.
Again, the same actual examples: R Commander and Tinn-R... plus many
others.
[...]
> I think it's unlikely that I will be doing anything with the
> error/warning mechanism, but there are other people who might. So I'd
> suggest you propose a change that would meet your needs, and see if
> anyone responds.
...??? But that's what I am doing in this thread? Do I need to formulate
it in a different way, perhaps?
Philippe Grosjean
[...]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
