CLASSIFICATION: Language Processing SH: Y - UF CM: Y - C BM: Y - C
Project: 000 Supervisor: PJJ
The Java Compiler Compiler (JavaCC) is a parser generator created by Sun for use with their Java language. It is roughly equivalent to tools like Lex and Yacc, but has different underlying mechanisms. This makes it easier for humans to understand what it is doing, but also makes the basic system less powerful. Because of this, users have to put some effort into modifying an initial grammar to make it acceptable to JavaCC.
For example, we would normally recognise non-associative, left-associative and right-associative operators using non-recursive, left-recursive and right-recursive grammars respectively:
non_expression = sub_exp | sub_exp '=' sub_exp left_expression = sub_exp | left_expression '+' sub_exp right_expression = sub_exp | sub_exp '^' right_expressionHowever, with JavaCC, we have to rewrite the grammars:
non_expression = sub_exp ( '=' sub_exp )? left_expression = sub_exp ( '+' sub_exp )* right_expression = sub_exp ( '^' right_expression )?(We have had to left-factor non_expression and right_expression, and convert left recursion to iteration for left_expression.)
This project is about producing a program that helps users to modify their grammars, to get the most out of JavaCC. The program would be interactive, so that it could point out problem areas, make suggestions, and allow the user to pick a suitable modification. Some specific areas that could be investigated are converting left recursion to iteration, left-factoring and look-ahead and error handling.
I would expect the program to be written using Java and JavaCC.
REFERENCES:
JavaCC is now maintained by
Metamata.
You should be able to find
documentation
and a
FAQ.
A similar, but not identical, tool:
http://www.iit.edu/~tc/llk.htm
CLASSIFICATION: Language Processing SH: Y - LF CM: Y - F BM: Y - F
Project: 000 Supervisor: PJJ
This project consists of implementing an interpreter for the text-processing language TRAC. As an example of TRAC, the following:
#(ds,factorial,(#(eq,x,1,1,(#(ml,x,#(cl,factorial,#(su,x,1)))))))' #(ss,factorial,x)'defines the equivalent of a function, factorial, with one parameter, and:
#(cl,factorial,5)'invokes it to calculate 5!.
Initially you will concentrate on implementing the kernel of the interpreter, subsequently progressing to implementing some of the other primitive operations, or maybe even designing your own. You will have to write significant test programs in TRAC at all stages of the work. Alternatively, once you have implemented sufficient of TRAC, you could concentrate on writing a significant program in TRAC itself, such as a text processor.
REFERENCES:
A short introduction to TRAC:
http://www.cs.man.ac.uk/~pjj/projects/trac_doc
TRAC Language Institute
http://www.trac-language.org/
CLASSIFICATION: Language Processing SH: Y - LF CM: Y - F BM: Y - F
Project: 000 Supervisor: PJJ
Threaded code is a technique for implementing interpreters for computer languages, and is especially suitable for reverse-polish notation. (It has nothing to do with using "threads" to get the effect of multiple processes running in parallel.) This project consists of designing and implementing a threaded code language and system based on the paper reference, available from me.
Initially you can implement any sensible subset of 'Generalisations' 1 to 11 and any 'Advanced Concepts', including those from the bibliography, such as 'defining words'. It would be reasonable to aim initially at about generalisation 8 but to design your program to be easily extended. You will have to select your own set of primitive commands, including integer arithmetic and input-output. You should expect to enhance your language by implement new facilities such as virtual memory, filestore, parallelism, data structures, or any other features to be found in computer languages.
REFERENCES:
What is threaded code:
http://www.complang.tuwien.ac.at/forth/threaded-code.html
Kogge P.M.
An Architectural Trail to Threaded-Code Systems
IEEE computer March 1982 pp22-31
CLASSIFICATION: Language Processing SH: Y - LF CM: Y - LF BM: Y - LF
Project: 000 Supervisor: PJJ
The second-year language/compiler course, CS2111, uses lex and yacc in most of the lab exercises. However, these tools are specifically designed to be compatible with C, and we expect to make more use of Java over the next few years. There are several alternatives to lex and yacc that are compatible with Java - some are direct replacements, some are very different but with similar functionality. The aim of this project is investigate these various alternatives, and in particular to redo the various examples and exercises. The ultimate objective is to decide which of the available tools should be used in a future version of CS2111. It may be that more than one such tool is picked, as there are examples of several different classes of parser-generators available (e.g. bottom-up, like yacc, or top-down), and CS2111 could discuss their relative merits.
An obvious extension of this project would be to use the chosen tool to solve a bigger problem. One possibility would be to re-implement one of the programs I use to process student or timetable information, currently written in C.
REFERENCES:
CS2111:
http://www.cs.man.ac.uk/~pjj/cs2111/index.html
available tools are listed at:
http://www.first.gmd.de/cogent/catalog/java.html
COURSE PREREQUISITES:
CS2111 (or perhaps CS3041) would be a big help, but is not necessary
CLASSIFICATION: Graphical Systems and Applications SH: Y - F CM: Y - UF BM: Y - F
Project: 000 Supervisor: PJJ
Javadoc is a program that examines a set of Java class definitions and creates an html page describing each one, interlinked to show the relationships between them. For example, it is used to create the standard on-line documentation for the Java API. This project would be to write a program, using Java and JavaCC, to examine these html files and use them as the raw data to create the equivalent UML-style diagrams.
A simple version of this program would just draw a static diagram. However, typical Java projects involve more classes than could be drawn with enough clarity to be useful, so a more advanced version would include various forms of user interaction. For example, the user could move items around to help untangle complex diagrams, and the system might remember this for next time. Better yet, the system could initially put up a very simple diagram, and allow the user to "zoom in" to parts of it to see more details.
REFERENCES:
Javadoc:
file:/appl/webtools/JDK1.2/docs/tooldocs/solaris/javadoc.html
UML: e.g.:
http://home.cern.ch/~oreilly/PowerPointUML/index.htm
COURSE PREREQUISITES:
CS2111 (or maybe CS3041) would be a big help, and perhaps so would
CS2072, but neither is necessary
CLASSIFICATION: Language Processing SH: Y - C CM: Y - C BM: Y - C
Project: 000 Supervisor: PJJ
Rainbow is a language created in this department for designing asynchronous hardware. Rainbow designs look like ordinary programs, that describe the actions to be performed on the values flowing through the hardware. We have implemented a simulator for this language, so we can run the programs and watch their behaviour. However, we would like to have access to other kinds of tools that are available for use with other Hardware Design Languages (HDLs). The simplest way to do this is to create translators that can convert Rainbow programs to programs in the target HDL.
We have a Rainbow compiler written in Java, that parses a Rainbow program
to create parse-trees, checks them to deal with declarations and types, and
then outputs "code" for the simulator. This project essentially consists of
adding methods to each class used in the parse-trees, that will output the
target HDL instead of simulator code. This project actually has scope for 3
different students, each dealing with a different target HDL (if you choose
this project, you must also choose an HDL):
(a) VHDL
(b) Promela
(c) BALSA
The Rainbow language has several components (the main ones are Yellow, Green and Table), that can be used to describe different kinds of actions in different styles. It may be sensible to start the project by dealing with just one of these components. For example, it makes sense to concentrate on the Yellow component when translating to Balsa or Promela, as they are very similar.
Because of the intrinsic difficulties of translating between high-level languages, I really only expect a 95% translation, with the most difficult aspects being reported to the user for intelligent action.
REFERENCES:
Rainbow:
http://www.cs.man.ac.uk/fmethods/projects/AHV-PROJECT/ahv-project.html
VHDL:
http://vhdl.org/vi/comp.lang.vhdl
Promela (processed by Spin):
http://netlib.bell-labs.com/netlib/spin/whatispin.html
Balsa:
http://www.cs.man.ac.uk/amulet/publications/thesis/bardsley98_mphil.html
COURSE PREREQUISITES:
CS2111 (or perhaps CS3041) would be a big help, but is not necessary
CLASSIFICATION: Language Processing SH: Y - C CM: Y - C BM: Y - C
Project: 000 Supervisor: PJJ
Balsa and Yellow are languages created in this department for designing asynchronous hardware. These designs look like ordinary programs, that describe the actions to be performed on the values flowing through the hardware. (Yellow is actually a component of the Rainbow language - the other main components are Green and Table - that can be used to describe different kinds of actions in different styles.)
Last year, a 3rd year student implemented a translator from Balsa to Yellow, using JavaCC and Java. The output from this can then be used as the input to a Rainbow compiler (also written using JavaCC and Java) so we can run it on the Rainbow simulator. This project consists of integrating these two steps into one - i.e. modifying the Balsa translator to create the parse-trees that are currently created indirectly by the Rainbow compiler.
Extensions to this project could include using the facilities of the Rainbow compiler to improve the translation of the Balsa, and modifying the Rainbow language to include (a subset of) Balsa as another component - this could include suggesting changes to the rest of the Rainbow language to improve the integration of the final system.
REFERENCES:
Rainbow:
http://www.cs.man.ac.uk/fmethods/projects/AHV-PROJECT/ahv-project.html
Balsa:
http://www.cs.man.ac.uk/amulet/publications/thesis/bardsley98_mphil.html
Last year's project:
http://www2.cs.man.ac.uk/~schofid6
COURSE PREREQUISITES:
CS2111 (or perhaps CS3041) would be a big help, but is not necessary
CLASSIFICATION: Language Processing SH: Y - C CM: Y - C BM: Y - C
Project: 000 Supervisor: PJJ
Rainbow is a language created in this department for designing asynchronous hardware. Rainbow designs look like ordinary programs, that describe the actions to be performed on the values flowing through the hardware. We have implemented a simulator for this language, so we can run the programs and watch their behaviour.
The Rainbow language has several components (the main ones are Yellow, Green and Table), that can be used to describe different kinds of actions in different styles. It is expected that these different components will be used at different stages of the design. Typically, a design will start out in Yellow, which is similar to common programming languages. It will then be transformed into Green, which is closer to the real hardware, so that the user can modify any newly-visible details. For example, a variable in Yellow becomes a register in Green, and the user can adjust the connections to the hardware devices that set or use its value.
Currently, a user has to convert Yellow to Green by hand. We hope to help the user by providing automatic translations from Yellow to simple Green. We have a Rainbow compiler written in Java, that parses a Rainbow program to create parse-trees, checks them to deal with declarations and types, and then outputs "code" for the simulator. This project essentially consists of adding methods to each class used in the parse-trees for Yellow, that will output Green instead of simulator code.
Because of the intrinsic difficulties of translating between high-level languages, I really only expect a 95% translation, with the most difficult aspects being reported to the user for intelligent action. It may even be that a mechanical translation is too verbose, and that we would do better simply to generate some sort of framework so users can fill in the details.
REFERENCES:
Rainbow:
http://www.cs.man.ac.uk/fmethods/projects/AHV-PROJECT/ahv-project.html
COURSE PREREQUISITES:
CS2111 (or perhaps CS3041) would be a big help, but is not necessary
CLASSIFICATION: Language Processing SH: Y - C CM: Y - C BM: Y - C
Project: 000 Supervisor: PJJ
Rainbow is a language created in this department for designing asynchronous hardware. Rainbow designs look like ordinary programs, that describe the actions to be performed on the values flowing through the hardware. We have implemented a simulator for this language, so we can run the programs and watch their behaviour.
The Rainbow language has several components (the main ones are Yellow, Green and Table), that can be used to describe different kinds of actions in different styles. It is expected that these different components will be used at different stages of the design, with Green being used in the most detailed design. We then need to "compile" this design into the equivalent hardware, in a form known as handshake circuits, which can then be further processed by other tools.
We have a Rainbow compiler written in Java, that parses a Rainbow program to create parse-trees, checks them to deal with declarations and types, and then outputs "code" for the simulator. This project essentially consists of adding methods to each class used in the parse-trees for Green, that will output handshake circuits instead of simulator code.
REFERENCES:
Rainbow:
http://www.cs.man.ac.uk/fmethods/projects/AHV-PROJECT/ahv-project.html
COURSE PREREQUISITES:
CS2111 (or perhaps CS3041) would be a big help, but is not necessary
CLASSIFICATION: Graphical Systems and Applications SH: Y - F CM: Y - F BM: Y - F
Project: 000 Supervisor: PJJ
Rainbow is a language created in this department for designing asynchronous hardware. Rainbow designs look like ordinary programs, that describe the actions to be performed on the values flowing through the hardware. The Rainbow language has several components (the main ones are Yellow, Green and Table), that can be used to describe different kinds of actions in different styles.
One style that Rainbow does not directly include, but that hardware designers use, is State Machines (sometimes called Finite State Automata or FSA) and we would like to make some provision for it. This project has two main parts: creating a graphical system that designers can use to draw various kinds of state machines, and generating simple versions of these machines in Rainbow. For each part there are various options, so a simple version of the project would just explore one possibility, whereas a more complex version might provide more alternatives:
Should the FSA be deterministic or non-deterministic, and should the outputs be determined by the transitions or the states? In fact these are all equivalent, so what we are really looking for is convenience for users and simplicity of translation.
Should we generate Green or Table or Yellow? Green has a graphical form, which superficially looks very similar to state machine diagrams, so it may be easier for the user to relate to, or it may turn out to be very confusing. Table and Yellow are both textual, like normal programming languages, and either could be useable. Table, as its name suggests, is tabular, and seems well suited to the problem. Yellow is more like a conventional programming language, and may therefore be more understandable to a user.
For compatibility with the rest of the Rainbow system, I would expect this project to be implemented using Java (and JavaCC, if necessary).
REFERENCES:
Rainbow:
http://www.cs.man.ac.uk/fmethods/projects/AHV-PROJECT/ahv-project.html
CLASSIFICATION: goes here (see below) SH=C, CM=C
Project: 000 Supervisor: PJJ (ex WPRM)
The name says it all really. The project will be in Java. The major challenge is to nicely format graphic rich pages pages using only text. With the standard browsers just turning off the images means you end up looking at a very ugly page, and with a lot of wasted space. There is no guaranteed way of extracting all the relevant text from a web page, some are purely graphic, but lots of pages use graphics only for adverts or stupid icons which are best left off.
Ultimately the user should have flexibility as to how the pages are formatted. That means there should be various style options available, and in a really sophisticated version the user should be able to define their own styles.
REFERENCES: delete if none.
COURSE PREREQUISITES: delete if none.
EQUIPMENT: delete if none.
CLASSIFICATION: goes here (see below) SH: Y/N - and if Y, the grading (see below) CM: Y/N - and if Y, the grading BM: Y/N - and if Y, the grading
Project: 000 Supervisor: PJJ
This is windows based financial strategy exercise which enables teams to take control of a business and navigate it through a simulated business environment in order to achieve particular financial goals. A team will have to control the various aspects of its business including investments, staff relations, wages, advertising, marketing, expansions, etc. It will also have to react to internal and external factors such as stock market crashes and employee strikes. At the end of each simulated (i.e. not real-time) year, a team's business will be presented with financial accounts and analysis which will tell the team of their relative successes and failures. It is intended that groups of teams will interact with each other in the simulated business environment i.e. team businesses will exist within the same environment as each other. A team will have 5 simulated years in which to run their business, after which an analysis will be performed to identify the most successful business.
The task has been commissioned by Professor Richard Pike, a senior lecturer in the Bradford University Business management Department. As a result I have, in essence, a client with whom I can conduct regular meetings in order to establish the full set of requirements.
I DO NOT require a supervisor who is familiar with business management or financial management. However I do require a supervisor who is familiar with Java.
REFERENCES: delete if none.
COURSE PREREQUISITES: delete if none.
EQUIPMENT: delete if none.
CLASSIFICATION: goes here (see below) SH: Y/N - and if Y, the grading (see below) CM: Y/N - and if Y, the grading BM: Y/N - and if Y, the grading
Project: 000 Supervisor: PJJ (ex WPRM)
This project is to build an offline web crawler which maintains a collection of web pages which are checked regularly for meaningful changes. If there are any changes the pages are updated.
Meaningful implies not updating a page just because the adverts on the page have changed. One of the many problems is to determine how to tell the difference between interesting/uninteresting updates. The browser will also follow up new links which are added to pages and determine if they are interesting or not. Another problem is to determine how often to check pages.
REFERENCES: delete if none.
COURSE PREREQUISITES: delete if none.
EQUIPMENT: delete if none.
CLASSIFICATION: goes here (see below) SH: Y/N - and if Y, the grading (see below) CM: Y/N - and if Y, the grading BM: Y/N - and if Y, the grading
Project: 000 Supervisor: PJJ
Project desciption goes here. Must be in HTML format. E.g. paragraphs must be separated by
REFERENCES: delete if none.
COURSE PREREQUISITES: delete if none.
EQUIPMENT: delete if none.