CSE 341 -- Programming LanguagesAutumn 2003 |
Department of Computer Science and Engineering, University of WashingtonSteve Tanimoto (instructor) |
Group ProjectsVersion 1.0 of Dec. 2 |
Designing and Prototyping New Programming LanguagesDue dates: Topics due Friday, Nov. 21 at 12:30. Demonstrations Monday, December 8, in MGH 044 during class hour; either bring whatever software you will need to demo your language or arrive early and download the needed compilers, etc. Project reports are due December 15 at 5:00 PM.Turn-in requirements: Hardcopy of the report. Electronic copies of the program files, including your source code. If you have multiple files, create a README.txt file that lists the name of each file, and a brief description of it (one or two lines each). These can be turned in here. |
Language Design Document that includes... 1. A statement of what class of computations the language is intended for. 2. Analysis of the paradigm(s) involved in your language. 3. Description of the language in terms of (a) basic representations for operations and data. If you are doing an embedded language then you will probably be relying on the host language (e.g., Lisp or ML) for this. (b) new datatypes (c) new functions (d) new control structures (e) how the programmers using your language will put programs together out of the pieces you provide. 4. Whether your language is "Turing complete" and why or why not. 5. Literature references to the most closely related articles, books, or web pages. Example programs in your language: 1. One or two simple programs in the spirit of the "Hello World" programs to show a minimal working setup. 2. One or more slightly more complex programs that illustrate a particular language feature you provide. 3. One or more complex programs that show an "application" using your language. Such a program will probably be about 2-3 pages of code. Documentation of your programming environment. This may include any of the following... 1. Interpreter for your language... how does it work? 2. Debugging or visualization facility. 3. Editor for programs. If you develop a visual language, this may be a sort of drawing interface. 4. Performance analysis features -- related to debugging in that it reveals information about the running of the program, but may emphasize resource usage rather than correctness. Instructions for using your language and for running a demo. 1. Full path information to finding your software and documentation on one of the departmental machines such as cubist. 2. How to start your software. 3. How to load a demo program that you provide. 4. How to load one's own program. 5. How to use any other facilities you provide. 6. How to quit gracefully. Project Retrospective 1. List of team members and what responsibility each one had. Each person should have some individual responsibility. 2. Biggest technical challenge faced by your group and how you met the challenge. 3. What you learned from the project. 4. What you would do differently if you were to do the project again under the same time constraints. What you would do if you had more time. Source Code Description 1. List of the names and paths of all files of code you have written, For each file give a few words describing the purpose of the code in the file, and giving the name(s) of the team member(s) responsible for this file. 2. URL or host + path for all your source code.Topics Forms (Due Friday, November 21 in class)