Programming Languages: Theory and Practice

(CIS 352 at Syracuse U)

Note: parts of this syllabus are subject to change with adequate notice to students.

An introduction to the design and implementation of programming languages, focused on operational semantics and interpreters. This course is heavily project-focused, and a specific emphasis will be placed upon training in algorithmic thinking and programming strategy.

Instructors:

• Kris Micinski, Asst. Prof at Syracuse ECS
  • Office hours for programming-related questions: Wednesday, 12PM to 2PM in room CST 4-185
  • Office hours, 5min questions or less (no debugging help): 30min after class
• Neda Abdolrahimi, teaching assistant
  • Office hours: Thursday in Person (3-118): 10AM-12PM, Tuesday on Zoom 10AM-12PM

Workload:

• Asynchronous video lecture units (at most ~80min per week)
  • I assume you have watched the videos before class; but no pressure to understand everything, I will recap during class. However, please think of recorded lectures as “the book.”
• 4 projects
• 5 programming exercises
• ~4-6 “handouts” (worth 2% each)
• 2 midterms, second is the last day of class. There is no final (i.e., no exam during the scheduled final period).
• This will be a project-heavy course. Approximately 3-5 hours per week outside of class is expected. I recommend against taking this course concurrent with other project-heavy courses.

Course Tags

The university recommends instructors label their courses with shared competencies. We intend for this course to fit the following:

• Critical and Creative Thinking
• Scientific Inquiry and Research Skills

Wednesday debugging hours (instructor led)

The professor will be available on Wednesdays, from 1:30PM to 3:30PM. Please plan to take either a five, 10, or 15-minute block. If you plan to take more than 15 minutes, you may be asked to share time with other students.

This time is for debugging and to get critique on your code style. Please be mindful of the collaboration policy below–it is fine to watch along in office hours, but be careful not to use it as a crutch to develop your own solution.

I will try to avoid canceling Wednesday debugging hours. Unfortunately, sometimes I may get busy on Wednesdays with research-related work or deadlines from other service obligations. In the event I do need to cancel, I will let you know as far in advance as I can. Please email me to set up additional extra office hours in this event, I am eager to meet.

After-class office hours

The professor will generally make himself available for up to 30 minutes after class. Please avoid asking code related questions at the end of lecture, especially because there is another class that enters directly after ours. This would be a good time to come if you have content-related questions that can be addressed at the whiteboard or just via talking, without looking at your code.

Grading

• Exams – 40%

  • Two midterms. Midterm 1 will be partially before the mid-point, and midterm 2 (the “final”) will be on the last day of class. Each exam is worth 20%. Focus topics will be announced via electronic announcement (e.g., on Slack) a day or two before the exam. Students are allowed a handwritten, one-sided, US letter-sized note sheet.

  • Both exams are comprehensive, and a study guide will be provided several days before the scheduled exam.

  • For the first exam (but NOT the second, due to time constraints) students will be allowed to submit corrections which will allow them to get back up to 50% of their missed points. For example, if a student gets a 50% on their exam, and they successfully submit corrections, they will receive a mark of 75%. We will specify in detail what is required the day we return the first midterm.

• Autograder Projects – 40%
  • 4 individual programming projects worth 10% each.
    • Collaboration/ChatGPT/… IS NOT allowed on projects. See the AI usage policy below.
• Autograder Exercises – 10%

  • 5 Autograder-based programming exercises, worth 2% each.

    • Working in groups (up to three) is explicitly allowed, however:

    • It is required that all work on exercises be conducted together. It is not acceptable for one groupmate to do the work without others present and have others submit. It is also acceptable to work alone (or in a group of two).

    • Collaboration/ChatGPT/… IS allowed on exercises

    • It IS NOT permissible to share your coding exercise solutions with classmates outside of your group.

• Handouts/Homework – 10%

  • There will be (at most) 5 “handouts”/homework assignments weighted equally, these will mostly occur in the later part of the course.

  • These assignments will be either (a) handed out in class or (b) completed on Blackboard. Copies will be distributed online for students not present in class. Deadlines will be set on a per-assignment basis.

• Bonus Points – Up to 4%

  • I will offer several bonus handouts / exercises. These will take various forms. For example, one is a history writeup about the lambda calculus which requires you to write a paragraph or two. These will be announced in class, please ask for details if you are unsure.

Final letter grading bars

Final grades will be assigned as follows. A small “bump” (0-2 points usually) will likely be given in practice, but is not guaranteed–this will be announced at the end of the course, though I will try to provide a ballpark estimate on Slack before the second midterm.

• A – 92%
• A- – 90%
• B+ – 87%
• B – 83%
• B- – 78%
• C+ – 74%
• C – 70%
• C- – 65%
• D – 60%
• < D – < 60%

Topics

• Functional programming in Racket/Scheme
• Forms and callsites
• Lexical environments and scoping
• Textual reduction semantics
• Structural recursion over inductively-defined lists
• Higher order functions (lambdas) and their properties
• Cons diagrams and boxes
• Quasiquoting and pattern matching
• Tail calls and tail recursion
• Metacircular interpreters
• Natural deduction
• Small-step semantics
• Lambda calculus
• Reduction strategies
• Closure-creating interpreters
• Church numerals, church encoding
• Fixed points and fixed point combinators
• Continuations and call/cc
• Principles of compilation
• Compilation of primitives, let, and if to pseudo-assembly
• Overview of more advanced compilation topics: instruction selection, calling conventions, register allocation, etc…

Autograder Exercises / Projects (50%)

There are four individual programming projects in Racket. Projects will be graded using an autograder whose URL is https://autograde.org. You will receive credentials for the autograder–if you have not received these by the second week of class, let the professor know. You are expected to learn how to use the Git interface to the autograder–the autograder will technically accept archives, but the instructors strongly prefer students (and will exclusively help support) using Git. Again, you must learn Git to use the autograder.

There will also be between four and six group programming exercises in Racket. These exercises may be done in groups of up to three students. Groups MUST write their solution together (Zoom/video call is acceptable, but it must be synchronous).

Exercises and projects will be weighted at point values of 100 points (exercises) and 1000 points (projects), so that projects are worth roughly 10x as much as exercises. Exact grading weights on the autograder are subject to change pending sufficient notice to students, but will never be more work (or less advantageous to students) than the grading bars specified here.

Project / Exercise Late Policy

• Projects and exercises turned in within 72 hours of the deadline will receive a 15 percent penalty. Projects turned in after 72 hours and until the end of the course will receive a 25 percent penalty.

• I will NOT grant one-off project extensions without good reason. There is a liberal late policy. I encourage you to take the 15% off and submit late–many projects will have bonus points that will allow you to raise your grade and offset late submissions, and a single late submission will likely not change your final course grade.

• I am happy to move project deadlines for religious observances, excused medical absence, and similar unforeseen circumstances. Please email me and we can discuss a satisfactory resolution.

Exams (40%)

Exams explicitly measure your ability to materialize solutions to questions regarding relevant course content in an open-ended fashion. There will be two midterms. Questions will be drawn from the learning objectives at the top of the page. I will release a practice exam several days before both midterms, which we will work through in class.

After the first midterm, you may submit corrections for up to 50% of missed points back. Details will be provided after the first midterm. There will be no corrections for the second midterm.

We realize exams can be stressful. The instructors strongly encourage students to look into the resources provided by the Barnes Center (such as extended exam time) if a student thinks their academic performance is impeded by exam-related stress. We are happy to provide accomodations for exams, but the instructors request at least 72 hours notice for each exam so that we may upload the necessary material to the student testing center.

Handouts/Homework (10%)

There will be (at most) five equally weighted on-paper (or on-Blackboard) homework assignments. These handouts / homeworks will primarily be weighted towards the end of the semester, after projects are wrapping up. For example, content on the simply-typed lambda calculus will have (several) handouts attached.

Collaboration and the Honor Code

• Projects and exams must be completed alone, without exception.
• Specifically, you must never send your code to anyone or allow anyone to watch you code, obtain your code, study your code, copy your code, etc… We expect you will take reasonable precautious to ensure the secrecy of your solutions (e.g., closing your laptop before leaving your apartment, if living with other students).
• The autograder employs elaborate cheat-detection techniques, including advanced static analyses. These techniques will compare your code to other students’ submissions, along with students from previous semesters. The TAs and instructor will be using these features to periodically scan for students who are cheating. Past experience shows us that this system is very robust, and has allowed us to detect several large clusters of collaborating students; all violations ever reported in CIS352 have been upheld by the Syracuse University academic integrity council.
• All apparent cases (with credible evidence, as determined by lead instructor) of academic dishonesty will be reported, even if the student believes they made an honest mistake, or no mistake at all. We understand honor violations are stressful processes, and thus we strive to only submit academic integrity cases when we believe there is clear evidence that the academic integrity board should review our findings independently.
• You may collaborate, to any degree you want, with anyone (even outside of your group) on in-class or self-study exercises. These will be clearly labeled, and are specifically not the course projects (which explicitly disallow any form of collaboration).
• While we recommend you discuss the project specification with your peers, you should basically never be getting help from peers about your code. In particular, you should never be showing another student your project code. If you do discuss coding about the project with another student, it should only be in the abstract (e.g., “can you use operator overloading to implement that?” or “do you think it would be sensible to implement this with map?”) and not particularized to your codebase. We understand that this can be a challenging line to walk, and thus, we recommend the following heuristic: when talking to other students about code, discuss mostly the in-class exercises and participation coding exercises.
• You may not “hard code” solutions to tests for projects. The TAs and professor will audit all student solutions, and use automated static analysis tools, to check for potential hard-coding or other practices that circumvent the spirit of our automated tests–hard-coding solutions is considered a particularly offensive violation and will be immediately reported to the academic integrity board.
• Cite all help other than the professor, T.A., and required/recommended text (you are allowed to cite those if you wish, but it is not required unless you are specifically told otherwise). Proper citation is not sufficient to avoid any charge of academic dishonesty (e.g., citing another student’s work from a previous semester), but we will not be particularly focused on copyright law and it is permissible to use small snippets of code from Stack Overflow (or related sources such as books and notes) that do not tangibly complete the substance of the project for you. Again: You should never share code with another student. This includes both sending a file to another student and “over the shoulder” copying (even when, e.g., variable names are changed, etc..). In the eyes of the instructor, these are both equally bad. You should never be sitting and helping another along by writing their code. By doing so you are both violating the honor policy and disadvanting the student you are helping (as they may not then properly learn the material).
• If a student is found (by the university academic integrity council) to have violated the academic integrity policy, the instructor reserves the right to impose any grade-related sanction they see fit, up to and including course failure–regardless of the level suggested by the academic integrity council.

Official AI policy

Per university policy, I am required to use university-provided language, thus, here is the official class AI policy:

Based on the specific learning outcomes and assignments in this course, artificial intelligence is permitted on the following: autograder exercises (NOT projects), which are clearly labeled and worth 2% each. See each assignment, quiz, or exam instructions for more information about what artificial intelligence tools are permitted and to what extent, as well as citation requirements. If no instructions are provided for a specific assignment, then no use of any artificial intelligence tool is permitted. Any AI use beyond that which is detailed in course assignments is explicitly prohibited except when documented permission is granted.

The following is an informal justification for my policy as it relates to the class, CIS352, giving more context:

Large Language Models and similar machine-learning-based tools have the potential to radically change the way in which humans perform their work. The course instructor does research in AI and understands the value in using ChatGPT and similar tools to help learn and study (henceforth we casually conflate ChatGPT and similar LLM-based tools). However, these tools should be used carefully, and never in a way that undermines the spirit of expending genuine mental energy to understand the material in the class. I (the instructor) have used ChatGPT myself for quick answers to routine tasks, particularly in shell scripting and usage of common development tools. However, I do not find ChatGPT sufficient in serious work–I have found the code and writing it produces is often immature at best, and downright incorrect at worst. It can be challenging for newcomers to tell the difference between these, and thus while I do recommend considering ChatGPT as part of your problem-solving toolbucket.

I recommend the following guidelines (consistent with the official university-provided text above) for this class, CIS352. In the following “ChatGPT” refers to all tools based upon generative AI:

• Usage of ChatGPT is permitted to help study and understand material from class.

• Usage of ChatGPT is permitted on programming exercises–but not projects–provided that students provide the prompt they used in a comment and are honest about their usage of it.

• You may not submit any code generated by ChatGPT for programming projects, but you may look at the output of ChatGPT and use it to inspire your own solution with regards to small helper functions. I have tried each of the programming projects in this class using ChatGPT myself, and I also do research in program synthesis using symbolic methods: I can confidently say that ChatGPT cannot yet solve the course projects, and when I tried to use it to do so it led me down a path to deeply broken code that would confuse any student. There are code-oriented language models (e.g., Facebook’s Code Llama or GitHub’s Copilot) which do slightly better (albeit without an easy-to-use interface), but still do not work for the course projects because there is not a sufficient corpus of Racket available to train from.

• Because you may not submit any ChatGPT-generated code in project submissions, it is specifically not acceptable to say that you submitted the same code as another student because it was generated by ChatGPT. Duplicate project submissions (officially disallowed), even those due to identical outputs of ChatGPT, will be considered honor code violations.

Slack/Email Policy

Please keep all questions related to course projects and policies on Slack–I use Slack quite a bit more than email, and only check email a few times a day. Note that FERPA requirements prohibit me from discussing precise grades on Slack–for any question related to course records, please use email instead.

For official business (notifications of course absence due to illness, or similar extenuating circumstances, etc…) please email me. I will work to acknowledge emails within 24 hours. I sometimes miss emails due to the large volume of email I receive; please feel free to email me again after 24 hours if you have not received an answer and I will get back to you as quickly as I can.

Please do not ask for extensions over email or Slack unless you believe you have an approved accomodation–there is a blanket late policy in place which takes precedent here, and the Autograder does not allow one-off project extensions.

Student Support

Syracuse University values diversity and inclusion; we are committed to a climate of mutual respect and full participation. There may be aspects of the instruction or design of this course that result in barriers to your inclusion and full participation in this course. I invite any student to contact me to discuss strategies and/or accommodations (academic adjustments) that may be essential to your success and to collaborate with the Center for Disability Resources (CDR) in this process.

If you would like to discuss disability accommodations or register with CDR, please visit Center for Disability Resources (https://disabilityservices.syr.edu/). Please call (315) 443-4498 or email disabilityresources@syr.edu for more detailed information.

Accreditation and Use of Student Work

As part of the regular ABET accreditation process for the undergraduate program in computer science, we may be collecting samples of students’ work in each of our undergraduate classes. As a result, some of your labs/homeworks/exams may be photocopied/scanned (or electronically copied) to be presented for accreditation at some later point.

Faith Tradition Observances

Syracuse University’s Religious Observances Policy (https://policies.syr.edu/policies/university-governance-ethics-integrity-and-legal-compliance/religious-observances-policy/) recognizes the diversity of faiths represented in the campus community and protects the rights of students, faculty, and staff to observe religious holy days according to their traditions. Under the policy, students are given an opportunity to make up any examination, study, or work requirements that may be missed due to a religious observance, provided they notify their instructors no later than the academic drop deadline. For observances occurring before the drop deadline, notification is required at least two academic days in advance. Students may enter their observances in MySlide under Student Services/Enrollment/My Religious Observances/Add a Notification.

Student Mental Health

Mental health and overall well-being are significant predictors of academic success. As such it is essential that during your college experience you develop the skills and resources effectively to navigate stress, anxiety, depression and other mental health concerns. Please familiarize yourself with the range of resources the Barnes Center provides (https://ese.syr.edu/bewell) and seek out support for mental health concerns as needed. Counseling services are available 24/7, 365 days a year, at 315.443.8000.

Discrimination and Harassment

The University does not discriminate and prohibits harassment or discrimination related to any protected category including creed, ethnicity, citizenship, sexual orientation, national origin, sex, gender, pregnancy, disability, marital status, age, race, color, veteran status, military status, religion, sexual orientation, domestic violence status, genetic information, gender identity, gender expression or perceived gender.

Any complaint of discrimination or harassment related to any of these protected bases should be reported to Sheila Johnson-Willis, the University’s Chief Equal Opportunity & Title IX Officer. She is responsible for coordinating compliance efforts under various laws including Titles VI, VII, IX and Section 504 of the Rehabilitation Act. She can be contacted at Equal Opportunity, Inclusion, and Resolution Services, 005 Steele Hall, Syracuse University, Syracuse, NY 13244-1120; by email: titleix@syr.edu; or by telephone: 315-443-0211.

If you notice any incidents of harassment or discrimination in class or related venues (Zulip, other chats with students), however minor, please email me. You may wish to use an anonymous email service such as https://anonymousemail.me/. Please feel free to tell me as much as you feel comfortable. As a notice: I am a mandatory Title IX reporter and thus am legally-compelled to report incidents such as sexual harassment, relationship violence, stalking, etc…