From h.wickham at gmail.com  Fri Mar 21 16:29:31 2008
From: h.wickham at gmail.com (hadley wickham)
Date: Fri, 21 Mar 2008 16:29:31 +0100
Subject: [Rd] Roxygen
In-Reply-To: <47E38FCB.2050104@stats.uwo.ca>
References: <47DFD659.40506@stat.uni-muenchen.de>
	<20080319151841.GB15511@klutometis.wikitex.org>
	<47E14D5E.7090105@stat.uni-muenchen.de>
	<20080321060928.GA1283@klutometis.wikitex.org>
	<47E38FCB.2050104@stats.uwo.ca>
Message-ID: <f8e6ff050803210829l20cd5617ga57e45ef25e8b7cb@mail.gmail.com>

On Fri, Mar 21, 2008 at 11:36 AM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> On 21/03/2008 2:09 AM, Peter Danenberg wrote:
>  >> 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?
>
>  I don't know Manuel's intentions, but I'd say you should make use of the
>  parse() function, not source.  parse() converts source into unevaluated
>  expressions.  If you start writing your own parser of R code, it will be
>  hard to validate, and hard to maintain, because there are occasional
>  tweaks to the R definition.
>
>  parse() currently does nothing with comments, but it does tell you where
>  each parsed expression came from, so your code could use that
>  information to look again through the source for the bits that interest you.

But you'll still need a formal grammar for the documentation comments.
 Borrowing the basic style of javadoc should suffice, although there
are some tricky issues with line-endings etc.

Hadley

-- 
http://had.co.nz/



[Rd] Roxygen
hadley wickham