Martin Morgan wrote:
>>> 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.
>> I don't know a better isLineComplete function currently, but if parse()
>> returned more structured error information, it would be easy to write
>> one. (Of course, we might not need one in that case...)
>>
>> I think that's a better approach, and it's definitely something that I
>> am interested in working on. It seems to me to be a waste of my time to
>> make internal changes that will not only allow, but *force* all GUI
>> writers to replicate the R console. It should be easy to do that (and
>> it's not now), but it should also be easy to do something quite different.
>
> Prof. Ripley improved the mechanism for handling this at the C level
> during the last release cycle. The basic strategy is
>
> #include <R_ext/Parse.h>
>
> SEXP parses(SEXP cmd, SEXP rho) {
> ParseStatus status;
> SEXP res = R_ParseVector(cmd, -1, &status);
> switch(status) {
> case PARSE_NULL:
> case PARSE_OK:
> break;
> case PARSE_INCOMPLETE:
> ...
> break;
> case PARSE_ERROR:
> ...
> break;
> case PARSE_EOF:
> ... /* not sure we ever reach here -- incomplete before eof */
> break;
> }
> return res;
> }
>
> my implementation of '...' is to signalCondition, so at the R level
> you can detect the outcome in a tryCatch, something like
>
> expr <- readLines(file, 1)
> expr <- tryCatch(.Call("parses", expr, environment()),
> parse_incomplete = ...)
>
>
> Martin
Oh, very nice! I'll look at this. Many thanks.
Philippe
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
