In class we've seen the language JayJay (Jay extended for extra control structures); we would like to have an interpreter for it, as we had for Jay. But why waste all the work we've done already in writing a Jay interpreter? Since JayJay doesn't actually add any new functionality, we could write a JayJay interpreter merely by writing a translator from JayJay to Jay and slap it on top of the existing Jay interpreter. That's what you'll do in this project.
Copy and untar the framework for this project.
cp ~tvandrun/Public/cs365/proj3.tar tar xvf proj3.tar
The directories for this project contain
jay
package, containing most of the work we have
done on Jay
jayjay
package, containing the parser, abstract syntax,
and visitors for JayJay, including a stub for TranslatorVisitor
,
which you will write.
Count.jayjay
, a sample JayJay program.
The main program for JayJay (jayjay/jayjay.py
)
reads in a JayJay file, produces an abstract syntax representation for it,
and then applies a TranslatorVisitor
on the tree,
to produce a corresponding Jay
program.
It then uses the Jay interpreter from the jay
package
to execute that program.
jayjay/jayjay.py
can give you the big picture.
Your task, then, is to write TranslatorVisitor.py
.
There are two ways to go about this translation task.
One option is to have your visitor produce the text of
a Jay program (so, its result would be a string).
The Jay parser would then be used to parse that text and produce
the abstract syntax trees for the Jay program.
(One of the given files contains a JayJay uglyPrinterVisitor
,
which you could use as a model (or more than a model---a source for
a big chunk of the code) for producing Jay text.)
The other option would be to skip the text and the Jay parser and for your visitor directly to modify the JayJay syntax tree until it is a Jay syntax tree. This option would require you to produce new AST nodes and replace others. Note that Python duck typing means that JayJay AST classes and Jay AST classes can work together in the same tree; this would not be the case if we were writing in Java.
This project is set up so you may choose either option.
If you choose the text-result option, then your resulting
Jay program must be stored in an attribute (ie, instance
variable) in the visitor called resultText
.
If this holds a non-None
value, then
the jayjay
program will parse it through the
Jay parser to make a Jay AST; otherwise, the
original JayJay AST will assumed now to be a Jay AST.
Here's the code that does that (precondition: the JayJay AST is
stored in ast
:
transVis = TranslatorVisitor() transVis.visit(ast) if transVis.resultText : if prnt : print transVis.resultText try : jAst = jay.parser.parser.parse(transVist.resultText) except SyntaxError : print "Jay syntax error" raise else : jAst = ast
Postcondition: the Jay AST is stored in ast
.
I don't think either option is inherently any easier or harder; they each have their advantages and liabilites. (It was a starker comparison last time I taught this class when this project was in Java.)
The project comes with several tools to help in your testing etc.
python jay/jay.py SomeJayProgram.jay
and python jay/typeCheck.py SomeJayProgram.jay
python jayjay/uglyPrint SomeJayJayProgram.jay
.
You can also use the class jayjay.uglyPrinterVisitor
to ugly-print any portion of the AST at any time,
for debugging purposes.
For example,
def visit_Conditional(self, node) : UglyPrinterVisitor().visit(node) ...
python jayjay/TypeCheck.py SomeProgram.jayjay
jayasjava.py
and jayjayasjava.py
which execute Jay and JayJay programs as if they were Java programs.
These are not in the tar file; you can find them in
~tvandrun/Public/cs365/util
Moreover, the program jayjay
has some options that
may be useful to you as you test the program.
The --print
flag will print out the Jay
program before it runs.
The --no-ex
will suppress execution of the Jay program.
Copy your TranslatorVisitor.py
to
/cslab.all/ubuntu/cs365/turnin/xxxxxx/proj3
where "xxxxxx" is [elliot|payton|davidemmanuel|nathan|gill|brandon|sean|simon]. I will grade your project by running it against a collection of test files.
DUE: Friday, Feb 21, 5:00 pm.