Is this the appropriate place for GSoC conversations?
If I understand the proposal correctly, there should be a lexer
(written in R) that exposes an API; that API would be used by
segregated mini-parsers (Roclets) which do the dirty work of Roxygen
-> {html, LaTeX, DocBook, ...} translation.
The lexer should ship with a proof-of-concept Roclet. Have I missed
anything?
Hey Peter,
> If I understand the proposal correctly, there should be a lexer
> (written in R) that exposes an API; that API would be used by
> segregated mini-parsers (Roclets) which do the dirty work of Roxygen
> -> {html, LaTeX, DocBook, ...} translation.
you do not have to write the lexer/parser completely in R, you can
use C/C++ and call the functions from R.
In my thoughts, I do not see the Roclets as mini-parsers, but as small
R programs working on the parse tree/list returned by one big
parser/lexer. They use the information in the parse tree and create
Rd-files, NAMESPACE file, caller/call graphs, .... But I do not know
if this is the best way and your API-idea sounds good too.
> The lexer should ship with a proof-of-concept Roclet.
Hm, not only a proof-of-concept Roclet, but a small set of meaningful
ones. An important one is the Roclet for creating the Rd-files.
If you have created a meaningful internal structure of the parsed
code, the Roclets are not too hard to create. I think. :-)
> Have I missed anything?
First point will be the creation of a list of document and development
assistance tags which are useful in combination with R. It is
desirable that these tags and their syntax and semantics be compatible
with those used by Doxygen and Javadoc, but extended with tags
important for R specific things.
Hope I could help you,
Manuel Eugster.
On Mon, Mar 17, 2008 at 11:56 PM, Peter Danenberg <pcd at wikitex.org> wrote:> Is this the appropriate place for GSoC conversations? > > If I understand the proposal correctly, there should be a lexer > (written in R) that exposes an API; that API would be used by > segregated mini-parsers (Roclets) which do the dirty work of Roxygen > -> {html, LaTeX, DocBook, ...} translation. > > The lexer should ship with a proof-of-concept Roclet. Have I missed > anything?You should probably also survey existing attempts - I have written something with ruby that suggest some ideas. I also have a number of packages documented with that format which could be used for testing - I'd be happy to reformat my existing documentation if it meant I would no longer have to maintain my quick and dirty (and buggy!) parser. Hadley -- http://had.co.nz/
> You should probably also survey existing attempts - I have written > something with ruby that suggest some ideas.Fascinating, Hadley; do you have a link to the source, by any chance? I imagine doing it in Scheme, Ruby or any language, for that matter, where creating DSLs is cheap; would be a joy.
> I do not see the Roclets as mini-parsers, but as small R programs > working on the parse tree/list returned by one big parser/lexer.So I imagine that coming up with the intermediate parse-tree representation would be part of the contract. What would you think, by the way, of writing the parser in a higher-order language; e.g. Scheme?
You might also want to look at the Rdoc setup in the R.oo package. While my 30 secs glance at Roxygen suggests that it is a more flexible system, Rdoc always you to keep the help inside the function source file. Kasper On Mar 19, 2008, at 8:15 AM, Peter Danenberg wrote:>> You should probably also survey existing attempts - I have written >> something with ruby that suggest some ideas. > > Fascinating, Hadley; do you have a link to the source, by any chance? > > I imagine doing it in Scheme, Ruby or any language, for that matter, > where creating DSLs is cheap; would be a joy. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
Hey Peter,>> I do not see the Roclets as mini-parsers, but as small R programs >> working on the parse tree/list returned by one big parser/lexer. > > So I imagine that coming up with the intermediate parse-tree > representation would be part of the contract.Yes, sure.> What would you think, by the way, of writing the parser in a > higher-order language; e.g. Scheme?No, we want a solution in R. I know that there are lots of other languages which are more suitable for writing a parser and designing a DSL, but the advantage of a R solution is that everything is installed and available on the system :-) No additional dependences! Manuel.
> You might also want to look at the Rdoc setup in the R.oo package.Hmm; Rdoc seems thorough enough. What remains to be desired?
> No, we want a solution in R.Would it suffice, by the way, to source() a file and introspect upon its objects with ls(), formals(), typeof(), mode(), and the like; or should we formalize, say, a BNF and write the accompanying automaton?
Hey Peter, sorry for the delay, I was on easter holiday.> Would it suffice, by the way, to source() a file and introspect upon > its objects with ls(), formals(), typeof(), mode(), and the like; or > should we formalize, say, a BNF and write the accompanying automaton?I agree with Duncan and Hadley. I think, a good way is to write a parser for the comments and use the parse() function for R code. Manuel.