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