CSC 420 Principles of  Programming Languages

Weber/Spring, 2014

Syllabus Announcements Assignments Examples Resources Project


Old announcements


A6: due 3/24
Modify your solution for assignment 4 to create an interpreter for the expression calculator language from the textbook.  In order to make it easier to handle variables, you may restrict variable names to one letter.  An uppercase letter should represent a different variable than a lowercase letter.  To implement the read statement, use the C scanf function.  The following line will read a value into the double variable buf:
scanf("%lf", &buf);
A5: due 3/12
Turn in your solutions to problems 3.1, 3.2, 3.4, 3.6, 3.7b, 3.9, 3.11, 3.15, 3.19 from chapter 3 (pp 163ff) of the textbook.  Remember that it will not help you on the test if you rely on the solutions floating around the internet.  In order to help you resist temptation. I will return submissions containing one or more solution from the web marked with a score of 0 and no opportunity for resubmission.
A4: due 2/26
Add productions and actions to these bison and flex input files to create a parser for the expression calculator example in the textbook.  Fig. 2.24 on p. 88 gives all the LR productions necessary.  The parser should accept any legal "sentence" by issuing the output Accepted when the end-of-file has been reached.  It should also print the name of the non-terminal that has been matched at the end of the production on which it appears on the left of the arrow. 

You'll find that you will need to compare strings in order to recognize the read and write terminals.  The function that compares strings in C is strcmp.  Issue the command man strcmp to get information about this function.

Email me the modified bison and flex input files, as well as all the .h and .c files generated by bison and flex.  It is not necessary to email me the executable (i.e., the a.out file).
A3: due 2/10
Turn in your solutions to problems 2.9, 2.12, 2.13, 2.17, and 2.18 from chapter 2 of the textbook. For problem 2.17, only extend the grammar for while statements and not if statements.
A2: due 1/31
Create flex input that specifies the regular expressions for the tokens of the calculator language in example 2.9 on p. 52, then use flex to generate a C program that will read in a stream of characters and group the characters into tokens, printing the name of the tokens assign, plus, minus, times, div, lparen, rparen, id and number.  Any comment tokens should just be dropped.  Also, for number and id, print the actual number or the actual id as well as the token name.

For example, given the input

a := 15 + 7  // Comment here.
your C program would produce
Turn in the flex input file and the C source code program that your input file produces.
A1: due 1/29
Turn in written answers to exercises 2.1ae, 2.2ae, and 2.4.




You have two options for your project.

  1. Select a topic from the Explorations sections of the exercises at the end of the textbook chapters that are listed in the syllabus as ones we covered or plan to cover, and write a 5 page paper on the topic.  You must follow the formatting rules supplied by the ACM SIG Proceedings Templates;  either Word or LaTeX2e is OK.  Also, your paper must have a list of references with at least 10 citations in the body of your paper, from at least 5 separate sources.

    Register the topic with me (it will have to be one not chosen by someone else and I will have to approve the topic) by April 2 at class time.   Topic registration is first-come-first-served. Papers must be written by individuals only; no teams.

    Topics registered so far:

  2. Pair up with one other student and write an REPL interpreter for a subset of Scheme.  You do not have to use C/C++ and flex/bison to do this project; other platforms, such as C# and Java may be better choices.  Note that there are tools like flex (jflex) and bison (byacc/j)  that work with Java, as well as some other languages.  Register your team and intended programming platform by April 2 at class time.  (I will have to approve the platform before you can start.)

    Your interpreter should behave in a manner similar to the mit-scheme interpreter; the user starts the interpreter and then can type in S-expressions that will be Read, Evaluated, and the result Printed.  The interpreter will Loop to allow the user to enter another S-expression after that, until the user signals an end to the input.

    Your code must be properly documented, well organized and nicely formatted.  You must also provide a short user manual (only a paragraph or two would be necessary) to explain to the user how to run the interpreter.  You may assume the user knows Scheme or can look up Scheme stuff elsewhere.  The user manual could be included in the interpreter and printed when the interpreter first starts, if the team so desires.

    Your interpreter must be able to:

    Extra credit will be given if your interpreter correctly handles

    Note that going for the extra credit may involve a totally different design than if you were just planning to implement the required features, so you should decide in advance whether you want to tackle the extra credit.

Whichever option you choose, the project is due, in its final form, on Monday, April 28.  It should be submitted electronically.  Submission of an interpreter should include all source code.  You may wish to take advantage of receiving feedback on a draft.  If you submit a draft by the end of Friday, April 18, I will do my best to give feedback by the following Wednesday.

Interpreter Implementation Notes