What is the original intent? The bandwidth:productivity ratio is not
looking encouraging for this problem.
Frank
On 07/13/2010 12:38 PM, schuster wrote:
Hello,
are you trying to pase SAS code (or lightly modified SAS code) and run it in R?
Then you are right: the hard part is parsing the code. I don't believe that's
possible without a custom parser, and even then it's really hard to parse all
the SAS "sub languages" right: data step, macro code and macro variables, IML,
SAS Procedures etc.
On Tuesday 13 July 2010 02:39:22 pm Roger Deangelis wrote:
Thanks Richard and Erik,
I hate to buy the book and not find the solution to the following:
proc.means<- function(....) {
deparse(match.call()[-1])
}
proc.means(this is a sentence)
unexpected symbol in "proc means(this is)
One possible solution would be to 'peek' into the memory buffer that holds
the
function arguments.
It is easy to replicate the 'dataset' output for many SAS procs(ie
transpose, freq, summary, means...)
I am not interested in 'report writing in R'.
The hard part is parsing the SAS syntax, I wish R had a drop down to PERL.
per1 on;
some perl code
perl off;
also
sas on;
some SAS code
sas off;
The purpose of parmbuff is to turn off of Rs scanning and resolution of
function arguments
and just provide the bare text between '(' and ')' in the function call.
This is a very powerful construct.
A function would provide something like
sas.on(
)
--
Frank E Harrell Jr Professor and Chairman School of Medicine
Department of Biostatistics Vanderbilt University
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
