Lambda Bound University of British Columbia, Department of Computer Science
CPSC 311 Definition of Programming Languages:
"Lambda Bound"

Winter 2018 Term 1

Course Goals     Syllabus     Notes     Assignments     Bonus Points     Piazza     Handback     Grades
Lambda Bound
CPSC 311, Definition of Programming Languages: Syllabus
  • Course Staff
  • Exams
  • Equity, Inclusion, and Wellness
  • Lectures and Tutorials
  • Course Materials
  • Assignments
  • Coding Style
  • Test Cases
  • Collaboration Policy
  • Collaboration Recommendations
  • Communication
  • Missing Lectures, Tutorials, and Exams
  • Grade Calculation
  • Acknowledgements
  • Course Staff


    Equity, Inclusion, and Wellness

    The CS Department has a fantastic statement on Equity, Inclusion, and Wellness with a large number of resource links available, for example if you have concerns or needs for accommodation.

    We hope that all of us in the CPSC 311 course also create a welcoming, respectful, inclusive, and positive environment. While CPSC 311 is unlikely to be stress-free (because learning is hard work, and hard work is often stressful), we also hope you will not find the course overwhelming. You may have ideas, questions, or concerns about creating such an environment in the course; we may make a mistake; or we may just plain do something wrong. If any of that happens, please let someone know. Talk to one of us on the course staff if you're comfortable or to someone from the link above (or the Head or Undegraduate Associate Head of the department) if you're not.

    Lectures and Tutorials

    Lectures are MWF 1000–1100 in DMP 310. Here is a tutorial schedule:
    TutorialDayTimeRoomTA Staff
    T1BMon11:00–12:00ICCS 014Felipe, Ziyang (who needs to leave about 8 mins early!)
    T1AMon14:00–15:00ICCS 014Felipe, Ziyang
    T1CTue15:00–16:00ICCS 008Sam, Ziyang
    T1DTue16:00–17:00ICCS 008Felipe, Sam
    T1EWed14:00–15:00ICCS 014Ziyang and Sam (tentatively; pending final size of the tutorial)

    We will write code on the fly and collaboratively in lectures. So, bring your active curiosity to class.. and your computer if you can! Do the reading (which means trying the exercises!) beforehand or expect to be left quickly behind.

    Tutorials will also explore course concepts hands-on and on the fly. Tutorial material will sometimes supplement and sometimes reinforce lecture.

    Come to tutorials prepared, having read assigned readings and attempted (or completed!) the current assignment. Those with laptops should bring them, although the tutorial rooms have some desktop computers.

    Course Materials


    Most of our programming will be in Racket using its DrRacket environment. DrRacket is installed on the department machines, and is available for free download. See Assignments page for more information on getting set up.


    People learn by doing, not listening. We will have regular assignments. The tentative term-long schedule is posted on the assignments page, including a schedule of assignment deadlines and deadlines for the end-of-term project.

    Read and adhere to the very open but absolutely required collaboration policy. See individual assignments for rules regarding teamwork.

    No late submissions will be accepted. Thus, we can release solutions right away, which gives you a chance to get feedback when it counts. However, if you have extenuating circumstances, please contact your instructor immediately, preferably in advance, and we will try to handle the situation empathetically, reasonably, and respectfully. Submissions that do not acknowledge collaborators and sources will receive zero marks and result in an official misconduct investigation.

    Coding Style

    A key theme of this course is expressiveness in programs. Thus, we require you to write code that is clean, concise, elegant, tested and appropriately documented. Your grade on programming assignments will depend on these qualities. In particular:

    Test Cases

    All functions must have unit tests that exercise the functions'.. um.. functionality. This is good software development practice but, more importantly, documents that you grok your code. When reviewing code, we will not give full credit to untested functionality, even if it is correct.

    Good test cases:

    When writing test cases, resist the temptation to make them massive and complicated (so they “must be testing something”). Instead, write small, clean tests with clear purposes. A mega-test may expose errors you haven't yet tested for, but if your mega-test fails, figure out which aspect failed and write a focused test for that.

    It's a fabulous learning exercise to try to create a parsimonious test suite. Try doing it carefully and intentionally a few times, and you'll find yourself more able to do it automatically in the future. You'll also have a clearer sense of the core functionality you want from your code.

    Collaboration Policy (for assignments)

    Our course builds on the department's academic integrity statement with additional rules designed to create a professional but collaborative environment: (Can you access sites like Course Hero? Technically yes, but please do not, as such sites contribute little to your learning. If you ignore this advice, bear in mind that you must acknowledge the sites you use and may not "take notes away". So, you have committed academic misconduct if you use such a site but do not acknowledge it or if you copy-and-paste material from such a site, regardless of acknowledgement.)

    These rules encourage collaboration that helps you learn. Nonetheless, submissions that follow these rules will not display the unusual properties that, under stricter rules, suggest academic misconduct. Thus, we will vigorously—but with great disappointment and annoyance—prosecute submissions that display these unusual properties.

    Collaboration Recommendations

    When you collaborate outside your team, follow the "Gilligan's Island Rule" (thanks to Larry Ruzzo, who inspired the whole collaboration policy): After discarding notes from a collaboration, spend at least an hour doing something at least as mindless as watching Gilligan's Island. If you can recreate your insights after such a mental emetic, you probably truly learned.

    When you work with your team, work together rather than "cutting up the problem" and working separately. (We may use code reviews and will use exams to enforce individual accountability for assignments.) To increase productivity and improve learning, use pair-programming techniques (of the form preached by Extreme Programming). Pair-programming in a nutshell:

    Plan ahead to schedule the face-to-face time this requires!


    We use several systems for communication:

    Within the confines of the collaboration policy, use Piazza for asking anything at all! If you're in doubt about whether something should be posted publicly, simply post it privately! We all benefit from that! However, you can also e-mail the teaching staff (see Course Staff) when you need us.

    Missing Lectures, Tutorials, and Exams

    You are required to attend all scheduled lectures, tutorials, and the final exam. If you miss a lecture or tutorial, catch up. Use (at least) the website, friends, the discussion boards, and office hours to do so. If you miss the final exam, you must follow the procedures defined in the Academic Concession Policy. Please see the Grade Calculation section for how to document missing a midterm exam.

    Grade Calculation

    Course components are weighted as follows:

    "Best of:"5%

    The instructor reserves the right to modify these weights (but does not anticipate exercising that right).

    You must pass the average of the midterm and final exams (weighted corresponding to the components labelled midterms/final above) to pass the course. If you fail this average, your course grade will be no higher than 45%. (Where we have group stages to the exams, we compute the pass threshold solely from individual scores; however, we do use calculated marks for the midterms, as described below.)

    Most assignments will have equal weight, but we will count a larger project at the end of the term as if it were four assignments, and we will drop your lowest assignment mark (so, one copy of the project mark, if that were the lowest grade).

    Each midterm exam will have equal weight. Your calculated mark for each midterm will be the maximum of the midterm mark you earned and the final exam mark you earned minus 10 percentage points. The midterms this term are in-class. So, if you miss one, please have (but do not yet provide) documentation for the reason you missed the exam and e-mail or post privately on Piazza as soon as possible explaining why you missed it.

    Your grade for the "best of" component will be the maximum of four options: your assignment average (i.e., the mark for the "Assignments" portion of the grading scheme, which includes your project as detailed above), your midterm average (i.e., the mark for the "Midterms" portion of the grading scheme), your final exam mark (i.e., the mark for the "Final" portion of the grading scheme), or your overall project mark.


    This year 311 is using Programming Languages: Application and Interpretation by Shriram Krishnamurthi as the course text. With Shriram's kind permission, we are borrowing heavily from other parts of his CS173 course at Brown. Many elements of the course are also based on prior work by Kris De Volder, Gregor Kiczales, Norm Hutchinson, Kurt Eiselt, Joshua Dunfield, and other previous course staff.