>> 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
--
Bioconductor / Computational Biology
http://bioconductor.org
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
