CS512 Winter 2007

Syllabus

Instructor: Dr. J. Michael Meehan
Office: CF473
Office Hours
Phone:
(360) 650-3795
Email: Michael.Meehan@wwu.edu


Contents

Catalog Description
Class meeting times
Collaboration
Grading Policies
Other texts you may find helpful.
Text

Class meeting times

Monday

Tuesday

Wednesday

Thursday

Friday

 

200-3:50


2:00-3:50


Contents
To Top of Page


Text

Programming Language Pragmatics 2nd edition, Michael L. Scott, Morgan Kaufman publishers, 2006

 


Catalog Description

 512 DESIGN AND IMPLEMENTATION OF COMPUTER PROGRAMMING LANGUAGES (4)

Prereq: graduate status or acceptance to undergraduate honors program in computer science*. Evaluation of programming language features, classification of programming languages in terms of expressiveness, complexity, uniformity and orthogonality. Cost of implementing and using programming language in view of compilation and run-time environments. Mapping of programming language features onto computer architectures. Alternative programming methodologies: functional paradigm, imperative programming, logic programming, data flow programming, explicit and implicit concurrency models.

 * You should also have have a course in automata theory.

Course Objectives

  1. This course teaches the student how to critically evaluate programming language features.
  2. The student will learn how to classify programming languages and to evaluate them in terms of expressiveness, complexity, uniformity and orthogonality, and intended domain.
  3. The cost of implementing and using programming language features will be understood both from the point of view of compilation and the run-time environment.
  4. The mapping of programming language features onto real computer architectures or abstract machines (as appropriate) will be understood in detail.
  5. The student should have a deep understanding of the major alternative programming methodologies utilized in the field and be able to critically evaluate and compare them including: functional paradigm, imperative programming, logic programming, data flow programming, explicit and implicit concurrency models.
  6. The student should obtain an understanding of the history of the design and implementation of programming languages. The student should appreciate how features in use in current programming languages have evolved and the factors that have influenced current methodology and practice in the field both from an academic perspective and an industry perspective. The student should be able to identify where a given programming language appeared historically, what its contribution was, and what language design issues were at the forefront of programming language design when the language appeared. If the language later evolved into subsequent versions the student should understand why the evolution occurred, i.e. what issues were being addressed, and how the designers addresses these issues with the new features (or lack thereof). The student should understand where various programming language features came from and what languages influenced the design of other languages.
Topic Level Syllabus           (Don't take the lecture hour estimates too literally)
The number of lecture hours assigned to each group of topics is a rough guess. Each class is unique and is composed of a group of students with their own backgrounds strengths and weaknesses. Each class asks questions about different things and I let the interest and curiosity and needs of each class to some extent determine how long we dwell on any given topic. This is an immense field within the field of computer science. This topic requires a lifetime of intensive study. There is more depth at every turn than can be accommodated in a single course. The textbook does a very good job balancing depth and breadth. If the class demonstrates a desire for more depth of a given topic than provided by the text I will accommodate within the overall time constraints of the course. The text is 875 pages. The second edition actually cut quite a lot of material from the printed text and placed in on the accompanying CD. You will be responsible for both the material in the printed text and the accompanying CD. In addition, there is a significant amount of material I will present in class that is NOT in the text or on the CD. You are responsible for all material presented in class.



Introduction 1 lecture hour
Reasons for studying concepts of programming languages Language evaluation criteria Influences on language design Implementation methods

Imperative Paradigm 24 lecture hours

Evolution of major imperative programming languages: FORTRAN, ALGOL 60, COBOL, BASIC, PL/I, SIMULA 67, ALGOL 68, Algol-W, Pascal, Concurrent Pascal, Modula, Modula-2, Modula-3, C, Ada, C++, Objective C, Oberon, Occam, MESA, Euclid, CLU, Java, Smalltalk;

The problem of describing syntax;
Formal methods of describing syntax;
The problem of describing semantics;
Formal methods of describing semantics;
Primitive data types and variables;
The concept of binding;
Type checking;
Strong typing;
Scope;
Scope and Extent;
Referencing Environments;
Named constants;
Variable initialization;
Arithmetic expressions;
Operator overloading;
Coercion in expressions;
Relational and Boolean expressions;
Short-circuit evaluation of Boolean expressions;

Assignment operations;
Mixed-mode assignments;
Statement level control structures;
Compound statements;
Selection statements;
Multiple selection constructs;
Repetition statements;
Unconditional branching;

Guarded commands;
Data typing;
Type compatibility;
Design issues for data types;
Character string types;
User-defined ordinal types;
Array types;
Record types;
Union types;
The problem of undiscriminated unions;
Set types;
Pointer types;
Implementing data types;
The concept of subprograms;
Design issues for subprograms;
Local referencing environments;
Parameter-passing methods;
Subprograms as parameters;
Overloaded subprogram names;
Generic subprograms;
Separate compilation issues;
Design issues for functions;
Accessing non-local environments;
User-defined overloaded operators;
The semantics of Calls and returns;
Blocks;
Implementing dynamic scoping;
Implementing subprograms as parameters;
The concept of data abstraction;
Design issues for data abstraction;
SIMULA 67 Classes;
Abstract data types in Modula-2;
Abstract data types in Ada;
Data abstraction and classes in C++;
Data abstraction and classes in Oberon;
Symmetric and concurrent subprograms;
Coroutines;
Fundamentals of concurrency;
Language features for concurrency;
Exception handling;
Various approaches to exception handling;
Exception handling in PL/I;
Exception handling in CLU;
Exception handling in Ada;
Exception handling in C++;
Exception handling in Java

Functional Paradigm 4 lecture hours

Mathematical functions;
Functional programming Languages;
Development of LISP;
LISP as a functional Language;
LISP functions that build LISP Code;
The functional argument problem;
The FP language;
Evolution of functional languages;
ML;
Haskell;

Logic Programming Languages 3 lecture hours

Predicate calculus review;
Proving theorems;
Overview of Logic programming;
The origins of PROLOG;
Elements of PROLOG;

Applications of PROLOG;
Deficiencies of PROLOG

Data Flow Programming Languages 1 lecture hour

The data flow model;
Data flow language design goals;
VAL

Object-Oriented Programming Languages 3 lecture hours

Object-oriented programming;
Object-oriented programming languages;

Roots of Smalltalk;
Overview of Smalltalk: expressions, methods, assignment statements, blocks and control structures, classes;
Type checking and generics in Smalltalk;
Evaluation of C++;
Object-oriented programming in Oberon;

Odds and Ins 4 lecture hours

The wonders of late bindings;
Perl;
SNOBOL;
Icon;
Idol;
Unicon;
APL;

Contents
To Top of Page


Grading Policies

I will discuss with the class alternative paradigms for evaluation and reach a consensus as to how we will proceed. The alternatives revolve around whether we have in-class or take-home examinations and whether we have programming assignments and to what degree the grade is based on tests versus other evaluations. What is non-negotiable is that there will be at least a project, a midterm, and a final exam and that no other single component can count more than the final exam. In addition, we can suppliment the midterm and final exams with other small exams to be taken on-line if needed.

Your grade will be determined based on the following percentages.

  • Midterm                  33%

  • Project                    33%        

  • final exam               33%

  • Programming Assignments? # 3,4,5,6,7,8? Readjust percentages accordingly.

NOTE: I reserve the right to revise these percentages at any time during the term.

A final raw score value for the course for each student will be determined using the percentages above. The grade distribution will then be analyzed and a final determination of a letter grade will be made based upon the student's position within the distribution. The raw score numbers have no meaning in relation to a letter grade using the traditional scales of 90-100, 80-90, etc. The only way to approximate your eventual letter grade outcome for the course is to analyze your position in the distribution after each raw score has been achieved. For this reason, I will post the distribution of the grades on the course web pages for each graded component..

 

Contents
To Top of Page


Submitting Your Work

There is a Linux machine in my office called django.cs.wwu.edu. This is my personal office computer that I use for all my office activities. I give accounts to all students in my classes for this machine. If you do not have an account on it already you should send me an email requesting an account. These accounts are tied to the departments Kerberos authentication system which is used to authenticate you to all *nix and M$ systems in the CS department. You need to simply tell me what your standard login id is and I will activate an account for you on my machine. Your password is whatever it is on the department servers.

There is a Apache web server running on django. The URL of the form http://django.cs.wwu,.edu/~login-id will point to a directory named html under your home directory on django (note you don't include the html directory in the URL). This is where you should build your web documents for your project and where you will submit all assignments. Be sure to give the html directory and everything in it permissions that enable everyone to read those files or others won't be able to see your webs.  A command like chmod -R o+r  will do it for the files. For any directories remember to give x permission. If you are not up on your *nix skills (shame on you, fix that)  do a man chmod command and read what it says or come see me and I'll help you.

To turn in programs or take-home exams simple place them on django in Courses/cs512/xxx where xxx is midterm, final, prog1 etc. I will access your work there and grade it.

In addition, I use django to make certain software available to you that may not have been installed in the labs in time for the course. For example, I have compilers and interpreters on django for all sorts of programming languages. It is possible that I may have a compiler on django for the language you need for your project. Please remember that django is my office computer that I use to read my email, write papers, etc. Feel free to use it but don't clog it up with huge amounts of work while I am trying to use it. If you need to use django for a long running job please use a “nice value” on your job.

Django can be accessed in a number of different ways. You can use VNC viewer to access django.cs.wwu.edu:0 (that's a zero not an Oh) This will give you a complete desktop of your choice (kde, gnome etc.) You can also log into django using ssh. You can copy files to and from django using scp. From django you can mount your files from the CS student file server if you wish (one way is using smb4k, there are others). You should also be able to mount your home directory on django from other machines in the CS department assuming the machine you are using is configured to allow this.

Collaboration

OK here is the legal mumbo jumbo that has to be said so we can nail you butt to the barn if we have to.

There is an official departmental policy regarding cheating. It is posted on the wall by CS Department Office. READ IT. If you are found to have been cheating, you will receive a grade of F for the entire course not just the assignment in question. This is for real, no discussion, no second chance, do not pass go, do not collect $200.

What constitutes cheating on a programming assignment?

You can discuss the programming assignments with each other, in fact we encourage you to do so. You can even talk to each other about how you plan to solve the problem at the design level. When it comes time to write the code to implement the program, it had better be 100% your own code. Using code from someone else's program constitutes cheating. Ridiculous attempts at disguising purloined code will be detected and will only serve to guarantee to invoke the wrath of the teacher. We've seen it all before, so don't bother. We have programs which analyze the submitted program files and rank similarities.  These programs are quite good. They understand the grammar of the programming language and are not just text based comparisons. Thus, variable name substitutions etc. will not disguise reused code. If you use code from a book or other source for a sort routine or some other supporting type of code you MUST give attribution in a comment prior to the code as to the source just as you would give attribution to a quote in a paper.

Contents
To Top of Page


Other texts you may find helpful.

 Concepts of Programming Languages, 7th ed. Robert W. Sebesta ISBN 0-321-33025-0

 

Contents
To Top of Page