Welcome to the "Translators" module for Computer Science 301. A course of this sort is pretty fundamental to Computer Science, and I have offered it for many years in a steady progression of small changes. It seems to have a reputation for being quite "heavy", but at the same time many (most?) people who have taken it in recent years will tell you that it is quite a lot of fun, and that you will learn a lot. The course will be offered by Pat Terry and is run over the equivalent of eight weeks. That means that there are just under 40 lectures, and 8 practicals. The first practical will be held in the first week.

Objectives

There are several intertwined objectives in the Translators course. You can read all about these in "SAQA-speak" on the course web-site. Essentially:

• We hope to heighten your awareness of imperative programming languages - how they are designed and how they are specified. In doing this we introduce various aspects of formalism and theory, besides some more informal material.

• We hope to give you an insight into the translation (compilation) process, whereby programs written in high- level notations are prepared for execution on low-level machines. We discuss the implementation of translators, and give you ample opportunity to experiment with these in the fairly intensive practical course that accompanies the lectures.

• We hope to show you how theory and practice combine, and how the benefits of being able to use formal notations come to practical fruition in the form of using compiler generators, which take formal descriptions of a language and from these derive major parts of a compiler.

Course Overview

The following are the main topics to be discussed in the course. These may not mean a lot at this stage, but hopefully will do so very soon:

Systems programs and translators - an overview
General structure of translators
Interpretive translation
Bootstrapping - getting the process started
Machine emulation and interpreters
Formal syntax of programming languages
Grammars
Parsing techniques
Parsers and Scanners
Syntax directed translation
Compiler generators
Attribute grammars
Translating simple high level languages
Block structure, functions and parameters

Course textbook

The prescribed text is Pat Terry's "Compiling with C# and Java". You might still be able to find a real copy at van Schaik's, and there may be second hand copies available on campus. In 2011 it went out of print, and we have updated, and made private copies of the relevant parts for you. These extracts can be found on-line.

You are welcome to browse http://www.cs.ru.ac.za/compilerbook/resourcekit/, the "Resource Kit" for the original book, but the necessary components of the softwar will be made available in the form of "prac kits" as the course proceeds.

A small reward (R1) is traditionally offered for the detection of each hitherto undetected silly typographical error, and a larger reward (up to R10) for the detection of more serious errors. Please keep on the lookout for errors (it's hard to get a book 100% accurate) and claim your rewards from the author.

DP Requirements

We draw your attention at the outset to the DP requirements for the course.

Although registers will be taken during lectures, there is no formal requirement that you attend a minimum number of lectures. There is, however, a formal requirement that to earn a DP for Computer Science 301 you should reach a measurable level of performance. In particular:

• You must achieve an average of at least 30% for the tests held in the semester. This includes the scheduled tests, the short prac tests that are a feature of the Translators module, and any "spot" tests that may be held at very short notice.

• You must achieve an average of at least 30% for the pracs held in the semester.

• You must hand in your practicals by the due time - before the start of the next prac, and not "during" the next prac. Unauthorized late submissions will simply earn a mark of zero, and will be counted as "missed".

• You may not miss more than two tests, or fail to submit more than three practicals over the duration of the semester. This total includes those missed with "leave of absence", for which arrangements are made for granting compensatory marks, as described in the departmental handbook.

Regular attendance at lectures will certainly help your chances of success in the course. And "borderline" students who just miss firsts, or just fail, but who have attended regularly will be treated more sympathetically than those who have stayed away. You have paid a lot of hard money in fees - come and get your money's worth!

Leave of absence

You are reminded that the Department does not always grant "leave of absence" for sporting or social events, or for people whose travel arrangements at the start and end of term tempt them to miss classes. Since we do not have a formal requirement that you attend lectures, this gives you quite a lot of freedom. However we stress again that we require tests to be attended at the scheduled times (I do not offer "make up" tests at a student's convenience), and we require that all pracs are submitted at the due date - so if you are ill for a day or two and miss a formal practical session you are still required to make up the work by the due date. Leave of absence for medical or compassionate reasons is accommodated as discussed in the departmental handbook.

Practical arrangements

In the Translators module, practical work is done on a group basis. Students must work in groups of two or three or, exceptionally 4 - please note that 2 or 3 means that, and not some small number between 1 and 10. This year a group size of three (3) is favoured, and by the time the first practical begins you should please have decided on your groups. Take some care over this, because of the obvious problems that will arise if you choose to work with people whom you don't know, or dislike. Please resist the obvious temptation to form a group of three and then let each person try to solve one part of each prac in isolation. You must try to master all of the material in this course, not just one third of it. The group experience is an important "side-effect" of the course objectives.

IMPORTANT - ignore these rules at your peril!

• Listings of your programs, properly headed, must be placed in the hand-in box outside the labs BEFORE the start of your next practical session on Thursday, packaged in plastic sleeves, and with completed cover sheets.

• I also want copies of your programs - source and executables, where appropriate - to be submitted electronically. But these are in addition to the printouts, not in place of them. I simply do not have time to print out masses of files before I start assessing your work.

• Please make sure that all files and listings have the names of each member of the group embedded in them (in comments), and also the names of other people with whom you might have cooperated.

• As the one who has to read your submissions, I stress that it makes an enormous difference to get nice readable solutions. Code printouts in large proportional fonts are quite unacceptable, sorry.

• Printing of files to be submitted should please be done by using the LPRINT utility which is set up to print listings of files with line numbers added, in a small font that allows for wide lines to be read easily, and with as many lines per page as possible to reduce your printing bills.

If you are ever required to hand in mini-essays or discussions, these must be typed - simple ASCII will suffice for me; I do not expect glitzy word-processed documents.

The practical exercises are designed to be done over a period of a few days. Properly done like that, you should find that they reinforce the material in lectures considerably. If you don't do them properly, I guarantee that the whole course will rapidly turn into a nightmare, instead of an enjoyable experience.

By this stage of your university career you should be starting to take pride in the quality of your coding - after all, in a year or two many of you may well be professional programmers. It should not be necessary to remind you to set out your code neatly, to insert proper comments, to include your name and a description of the program, and to use meaningful variable names. Don't cut corners - aim for quality in everything you submit.

Tests and Examinations

In place of a formal full-period module test there will be short tests at the start of most practicals on the work covered during the previous week and its practical exercises. Thus it is important that you make an effort to keep up, and really to understand your practicals.

There is a final examination for this course, which counts for 2/3 of the CSC 301 credit. Traditionally of the 180 marks allotted to this examination, something like 80 - 90 have been devoted to a single, practically oriented task which has been partly revealed to the class 24 hours before the examination proper, allowing the formal examination to incorporate a set of unseen questions based on this task. During the 24 hour period, students have been allowed and encouraged to cooperate in developing a quality solution to the task set. However, they have not been allowed to take any notes into the examination itself. During the formal examination they have been allowed access to computers and to most software used in the course, but there has been no obligation to use this if candidates prefer to work entirely "on paper". The final examination is usually held on a Monday, and is now nominally four hours in length - the time is extended if it is obvious to me that a little more time is warranted.

You are reminded that there are no supplementary examinations for Computer Science 3 courses. If you fail either CSC 301 or CSC 302, but achieve an average mark over 50%, then provided you have achieved at least 40% for the semester that you failed, you can obtain an "aggregated" pass. Note that this concession only applies when both CSC 301 and CSC 302 are taken in the course of one calendar year.

Cheating

Unfortunately, every year there are students stupid enough to try to cheat, steal other students' practicals, and so on. In the worst cases I have even seen stolen copies of my own model solutions submitted, but if there is one thing I can recognise it is my own work! In this course you are encouraged - even required - to work together. However, all names of people who have contributed to a prac submission solution must appear in proper comments at the top of all programs finally submitted, and appear on the cover page.

You are hereby warned that cheating is easily detected, and will be severely punished. A first offence will mean that all parties will simply get a mark of zero, be marked as having missed the practical in question and reported to the Senate Committee on plagiarism. If you are caught cheating again either in this course or in another, then the Department is require in terms of the official plagiarism policy to take the matter up with a committee who can impose really severe penalties such as exclusion, loss of DP and so on. Just don't be stupid!

Backup and support

As mentioned earlier, this is known as a "heavy" course. It is important that you establish good work patterns early. I have tried to provide as much backup as I can. In particular:

• do not be afraid to come to ask me for help. I assure you that I do not bite, and in fact very much welcome the chance for interaction and for getting to know you better;
• voluntary tutorials will be held every week from the second week onwards;
• solutions to prac exercises, prac tests, and formal tests will be posted on the web;
• demonstrators should be available in the lab on Monday, Tuesday and Wednesday evenings;
• later in the course you will be able to view copies of past exam papers (and solutions) on the web.

However, you will not find

• Power point slides - come to the lectures and take notes for yourself;
• Old tests and old pracs.

Web pages

We shall make a lot of use of the Departmental and Course WWW pages. Here are the URLS you should make a note of, and probably bookmark (we have internal links between these, of course).

CSC 301 Course page:
http://www.cs.ru.ac.za/courses/CSc301/
Translators course page (bookmark this one)
http://www.cs.ru.ac.za/courses/CSc301/Translators/trans.htm
These rules:
http://www.cs.ru.ac.za/courses/CSc301/Translators/rules.htm
Plagiarism policy
http://www.ru.ac.za/media/rhodesuniversity/content/institutionalplanning/documents/Plagiarism.pdf
(36 pages of legalese to find a way to say "don't be fool enough to try")
QA course description:
http://www.cs.ru.ac.za/courses/CSc301/Translators/qa.htm

Software

Unlike some other courses in Computer Science, the emphasis in this one is very much dictated by the maxim "keep it as simple as possible, but no simpler". To this end, although the practical work is quite intensive, it does not stress glitzy GUI interfaces, trendy visual programming, mastery of zillions of libraries, and so on. The work is probably best done largely using simple editors, simple compiling techniques, simple ASCII files, and so on - that is, it is adequately done at a "command prompt" level. The recommended way of doing some projects will be to set up simple "batch files" of commands; this will be explained as we proceed.

Most of the practical work will be done in C#. Please take note of the following:

• When you work on the local D: drive, please do so by creating a directory (folder) named with your account code, and then logging onto this. From DOS you would do this by issuing the commands

             D:
             MD D:\g14A1111
             CD D:\g14A1111
  

• Files created on the D: drive are stored only on that machine - there is no automatic copy made on a remote server or onto another machine. There is also no guarantee that the files will still be in existence next time you use the same machine. And, worse still, if you leave files lying around there is, sadly, the possibility that other students might copy them, and then hand them in as their own work. You are strongly recommended

  (1) to make backup copies of your files onto flashdisks;
  (2) and/or to backup your files onto your filespace on a server.
  

• We have little sympathy with students who try to make the excuse that they "lost their files" when the time comes to make a prac submission.

• We shall make use of "zipped" prac kits throughout the course; you will find sources for each week's prac in a file called PRACn.ZIP, which you can either copy directly from the I: drive, or retrieve from the link on the WWW page. Similarly, complete solutions will be distributed in the same way for further experiment.