Programming Language (Re-)Design Project

CISC 470/670 - Programming Languages
Fall 2000

DUE DATES:
	Part 1:PL Design (done in class on 9/14)
	Part 2:Preprocessor (Due 10/10/00 at start of class)

NOTE: This is a group project.  You will work in your
project work groups on
this project.  To promote everyone's participation in the group, 
the project will be graded,
and then each individual's grade will be computed by weighting the project
grade by a percentage that is determined to reflect your individual
effort on the project. 
The weight for your individual effort on the project will be 
determined through peer and
self reviews.
If your reviews indicate that you did not participate at all on the
project meetings, discussions, codings, etc, then your weight will be 0,
and your grade on the project will be 0.  If your reviews indicate that you
participated actively in the meetings and coding, etc, then your weight 
will
be 100, and your grade on the project will be the project grade itself.
Similarly, it is possible to get a percentage between 0 and 100, depending on
your individual effort.
Each member of the group can contribute in a variety of ways, but each should
be involved in some part of the coding and test case
generation.
This should be kept in mind when the responsibilities are divided among
the group.

PURPOSE: This project has several different purposes.
  - to take the role of a programming language designer, with a focus
on readability and writability by amateur programmer, given the set of features
offered by the language
  - to gain some experience writing context
free grammars in a practical setting 
  - to gain some experience with automatic scanner and parser generators,
LEX (FLEX) and YACC (BISON)
  - to gain some insight into how preprocessors are built
  - to gain some experience as a tester, creating test cases based on 
the specification of a language, 
building both legal test cases and test cases that 
are illegal in the language

MAJOR TASKS:
The project is divided into two parts:

	1. The Programming Language Re-design 
	2. The Preprocessor 

Programming Language Re-design

While PERL is quite powerful, it is not very readable. That is, it is very easy to create a PERL program that looks quite ugly to anyone other than the creator! This assignment focuses on creating a new language which maintains the same power (i.e., features and their semantics), but presents a much more readable, user-friendly language to the script programmer. This can be accomplished by the following steps: (1) Examine the PERL language and decide which constructs are already user-friendly, and include them in the new language without modification. (2) For other constructs, design a new more user-friendly set of tokens and syntax for expressing the same feature (with the same semantics). You should focus on the features of PERL most used by the casual PERL programmer, reflected in introductory books and tutorials on PERL. You do NOT have to create user-friendly new language for all of PERL. Because you are only designing the syntax and not the semantics or developing new features of PERL, you are creating a language which essentially "adds syntactic sugar" to PERL. Present this as a simple table with a column for your new user-friendly way of expressing that construct, and a column for the equivalent PERL construct's syntax. From this, create a list of the new tokens you will have in your language that do not exist in PERL. (3) Create a name for your new language (Be Creative!) (4) Develop a preprocessor that accepts programs written in your new language and outputs the equivalent PERL program. Steps 1-3 have already been done in class. Now, we focus on step (4) which is part 2 of this project.

The Preprocessor

The preprocessor should be implemented by writing a FLEX/LEX specification which is processed by FLEX/LEX to create a lexical analyzer, and then writing a BISON/YACC specification which is processed by BISON/YACC to create a parser. The FLEX specification should specify all of your tokens, while the BISON specification specifies your new syntax. The actions in the BISON specification are merely print statements to print out the equivalent PERL, as each of your constructs is parsed. The preprocessor driver consists of a program that calls your parser. The automatically generated parser will automatically call your scanner for you as it parses. There are links to the documentation for FLEX and BISON on the 470/670 course web page. There is an example of a simple preprocessor for my ridiculously wimpy redesign of PERL located on strauss at ~pollock/public/670/pldesign. In that directory, you will find lex and yacc specifications for my groovy language, a driver program, a makefile, and one groovy test program. You may copy these files and start your project by modifying them appropriately for your language preprocessor. You should probably start by just reading and following the directions in the README file in that directory to see how it all fits together into a groovy preprocessor. An easy way to get started with the preprocessor implementation is to modify my specification files to specify just one construct in your language, such that when the resulting preprocessor is run on a simple file with just that construct in it and legal perl statements, the equivalent PERL constructs are output. Then, incrementally add more constructs to your specifications. Eventually, delete my stuff unless you want your language include my groovy constructs. My groovy specifications are already set up to print out what was matched on input in the cases when I have included the original PERL constructs in the groovy language. You can do the same. It makes life really much easier. The parser is just echoing the input for these constructs when they are seen on the input. What to Hand in: You need to add to your web site or email with attachments to the TA, the following for this part of the assignment: (1) A table showing your language constructs and the equivalent PERL constructs. (2) Your FLEX specification (3) Your BISON specification (4) 3 test cases (with input data if not interactive) to demonstrate your language and preprocessor (5) Your Makefile for running FLEX, BISON, and compiling your preprocessor (6) A README File: Instructions on how to run your preprocessor The README should also indicate any nuances in order to use it properly, and your group members' names and contributions listed. The TA will be using your Makefile to compile your preprocessor and use your test cases to run your preprocessor. The generated PERL program will be run to check correctness. If your test cases seem trivial, additional test cases may be created by the TA to check correctness of your preprocessor. Criteria for Evaluation: PL Design: readability, usability, completeness Preprocessor: correctness (FLEX,BISON specs), efficiency Testing: test case generation - coverage of the grammar, sensible and those that stretch the grammar limits
Last Change: September 26, 2000 / pollock@cis.udel.edu