R-code in html help pages: syntax highlighting
Duncan Murdoch wrote:
On 16/03/2009 5:06 PM, Romain Francois wrote:
hadley wickham wrote:
It would be pretty easy to use the output from the R parser (which
is never
wrong, is it?), and dump some markup out of it. For example the
showTree
function in codetools dumps an R expression as Lisp, this is not
too far
from generating html, or any other markup.
As this sounds like fun, I'll volunteer to do something about this.
Another
advantage is that we can imagine to plug hyperlinks in R code that
lives in
html help pages.
This also sounds like a good idea for a google summer of code project - that way you might be able to get a student to give you a hand as well. Hadley
That did cross my mind earlier this evening, it just seems a bit too easy to last all summer, but maybe I am missing something difficult. I will start to play with this over the next few days, and make up my mind.
It depends on your standards. You said you want R to parse the code in the Rd file. That's going to be hard, because Rd files contain something that is only "R-like", as far as the parser is concerned. You'll need to convert it into R code before you can pass it to the R parser.
I would assume this would be outsourced to the experimental parse_Rd function
And then there's the question of scoping, which gets into the evaluator, not just the parser. (The parser only recognizes "mean" as an identifier; it's the evaluator that decides whether it's the function in the base package or a local variable.)
That is an issue. I guess I will fall back on what the parser says and
infer on the scoping. Within the lines below, mean would be different
each time
mean( 1:10 )
lapply( 1:10, mean)
mean <- (1+4) / 2
lapply( list( mean, median), function( f ) f( 1:10) )
{ mean <- median; mean( 1:10 ) }
So if you've got high standards, it's probably quite hard. On the other hand, if you're willing to accept the usual sort of errors that syntax highlighters make, it's not so bad, but not trivial.
There is probably some middle ground between the job an highlighter would do, and the way the R evaluator would think the expression eventually. Given that this is more a nice to have feature, I guess we can accept some errors. checkUsage is wrong sometimes, but it is still a good tool.
One of the problem I might run into is performance, if we want this to treat all Rd files, we are going to want something very efficient, and it might not be enough to build on top of codetools (which uses recursion at the R level) , but could make sense to provide a C level implementation.
Remember what Knuth said about premature optimization. Write it first in R, and only optimize it if it's not fast enough.
Deal
(I'd guess it'll be fast enough: Brian Ripley reported that all the R code he wrote for conversions in R-devel was faster than the Perl code it was replacing.)
That is good news
This could lead to interesting things as: - syntax highlighting in sweave (or decumar) - pretty printing in the console (using ansi characters) - syntax highlighting in R help files, potentially with hyperlinks I have requested creation of a project on r-forge. Anyone else want to play with this ?
I'll sign up once it's going. Duncan Murdoch
Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr