COMP 150PLD-Programming Language Design
Fall 2019
Welcome
Creating a new programming language requires designers to draw on a
wide range of skills: theory to create a
well-defined semantics, engineering to produce an
efficient implementation, and aesthetics to ensure the whole is
coherent and pleasing to programmers. In this class, we will study
the principles and tools that underlie programming language design.
We will consider both general-purpose languages, which are languages
intended for almost any programming task, and domain-specific
languages, which are languages focused on specific tasks.
Content will be presented in activities accompanied by pre-recorded lectures.
The class will be a combination of both interactive labs -- e.g. analyzing code artifacts --
and seminar-style discussions -- e.g. selected academic papers.
You will use the knowledge you
acquire to design and implement your own domain-specific programming
language.
Prerequisites are COMP40 (Machine Structure and Assembly-Languge Programming)
and COMP105 (Programming Languages).
Reading Academic Papers
In this class, we will be reading recently published academic papers
on both programming language designs and on tools for creating such
languages.
Reading technical papers is an acquired skill, and we'll work on
honing that skill in this class. You will read a new paper at most
once a week. You will be expected to read the paper in
advance of the class in which we start to discuss the paper and
then to participate actively in the class discussions. We will
structure our class discussions using a process
inspired by
this note (with thanks to Norman Ramsey)
and insights from the Tufts' GIFT program on group work.
Students will be active participants in discussions with roles and followup tasks.
The discussion structure enables us to understand
the intent of the languages and tools the papers describe, and document insights
that might apply to your technical writings and projects. The roles will
help divide and structure the group activities and provide individuals with
participation credit (see grading). The time commitment for these roles will be
mostly completed in class with at most two short follow up tasks for documentation.
Technical Writing
Effective technical communication is a critical skill for computer scientists.
For example, programming language designers can only convince programmers to use their languages
if the accompanying documentation is clear and compelling.
To help with your communication skills, we will be practicing technical writing at various levels of detail including
informal discussion notes, readme and github issue correspondences, wiki-style reference materials,
and, finally, formal academic prose. By practicing these skills
throughout the course, you will be able to focus on the
content of your final writing instead of on the means of conveyance.
Homework and Class Project
Picking up where COMP105 leaves off, this class starts with you applying the
skills you learned in the context of scheme and ML to programming in
Haskell. From there, you will write small
programs that will teach you idiomatic application programming in Haskell.
You will work from an end-programmer's point of view in a specific application
domain. By the end of the course, you will complete the class project, which is the design
and implementatioon of an embedded domain-specific language in Haskell.
The project includes picking a suitable domain of personal interest; identifying
the relevant features, representations, and abstractions;
designing a syntax; writing a parser;
and implementing a semantics via translation into Haskell.
We will be using Haskell's quasi-quotation metaprogramming feature to connect
these pieces into a cohesive embedded domain-specific language.
We will step through these tasks one at a time, and we will give you the tools necessary
to properly evaluate candidate domains before you commit to one.
You will be able to iterate and refactor your project given peer and instructor feedback.
The project will be delivered in two phases. The first half of the semester will
guide you -- with lots of scaffolding -- through the tooling from the bottom up.
From these exercises, you will produce a small (μ anyone?) DSL that works from end-to-end on a very-narrow
set of example programs. By touching each step in the language pipeline in the first half
of the course, you will have the context
to ask informed questions that will guide the rest of the project and
decide what is and is not in scope for your design given the time remaining in the semester.
The second half of the semester will be spent on applying lessons from the DSL
papers we read for class and from your classmates working in your domain to polish your DSL.
Collaboration and Sharing
Students will be required to work individually on their projects. Specifically, students
will produce their own Grammar,
Parser, Quasiquoter, Code Generators, and example programs.
To a limited extent, students may also work in groups. Specifically, if their
languages share a domain, students
may share runtime and library code relevant to that domain.
For example in the domain of card games, if student A is making a language
for programming turns in a game,
and student B is making a language for programming players of a game,
they may share a common representation of cards as an algebraic data type
defined in a separate library they maintain.
(Providing runtime and library support may make up the bulk of the code you
write this semester, but it is merely a pre-requisite to the metaprogramming
and DSL design concepts we intend to teach you. Thus, it makes sense to
allow you to share any helpful code that makes getting to the course objectives
easier.)
Grading
Your grade in this couse will be based 50% on class participation and
50% on the learning objectives.
Because of the importance of class
participation, you are strongly encouraged not to miss class.
Two participation points can be earned per class;
participation points are earned by the warm-up activity
and by fulfilling your assigned discussion role.
Missed points can be earned by going to office hours or by participating in the
online out-of-band activities on the CS Github at the
instructors' discretion.
At this link is the rubric of the 10 learning objectives
we hope you achieve by taking this course.
Each learning objective has 5 increasing levels-of-detail for their acceptance.
Each submitted assignment and discussion activity will be explicitly marked with
the learning objective and level of detail we expect from you for completing it.
With each assignment, you will submit some meta documentation,
e.g. a readme-like META.md file, that
explains how you earned that objective at that level.
The goal is to enable us to give you feedback quickly in a way that is relevant to your expectations
so that you may directly apply it.
This approach is inspired loosely by the feedback
process in COMP105 and from tricks learned in the GIFT program.
If you do not meet an assignment's stated objective at the time of the assignment, you may petition
for it again at times of revision or on other assignments that require the same
learning objective at a higher level-of-detail.
If you feel you meet more than the expectations mandated by the
assignment, you may also petition for higher levels of detail early. However,
early points will be at the instructors discretion and very difficult to receive;
so, please do not spend more time on those than the specified learning objectives.
For all learning objectives, add to your metadocumentation what objective and detail
you are petitioning for and why you have earned it.
Resources
Late Policy
Homework is expected to be submitted on time. Grading will most likely be done
immediately after class for improved feedback. Many times, the work turned in also
fuels that classes discussion.
If illness affects your ability to complete homework on
time, your first step is to report the illness using the "Illness
Notification Form" that is available in SIS under Resources (the
Settings icon). We will make suitable arrangements.
For extraordinary difficulties, such as bereavement, family
emergencies, etc., your first step
should be to contact your
associate dean for undergraduate education. You must take this
step before the assignment is due. Ask your dean to email Kathleen,
and we will make special arrangements that are
suited to your circumstances.
Academic integrity policy
Tufts holds its students strictly accountable for adherence to
academic integrity. The consequences for violations can be severe. It
is critical that you understand the requirements of ethical behavior
and academic work as described in
Tufts' Academic Integrity handbook. If you ever have a question about
the expectations concerning a particular assignment or project in this
course, be sure to ask us for clarification. The Faculty of the School
of Arts and Sciences and the School of Engineering are required to
report suspected cases of academic integrity violations to the Dean of
Student Affairs Office. If we suspect that you have cheated or
plagiarized in this class, we must report the situation to the dean.
Each student will be responsible for submitting their own work.
If any other student, material, online resource, or code referenced and is
non-obvious (e.g. code library dependencies) please add these references to your
metadocumentation -- e.g. META.md.
Feedback and Class Visitors
Some students have expressed interest in auditing this class. At this time,
we are allowing students to sit in and participate in discussion, but we ask
that priority for resources, attention, and interaction be given to students
who are taking this class for a grade. Auditors will be asked to complete
small in-class group exercises together.
Inspired by the GIFT program, Matthew and fellow graduate student teachers are
going to be visiting each other's classes. They will be introduced and may
interact with you during the class, but please feel at ease as they are not here
to observe or assess you and their interaction will have no impact on your grade.
The purpose of this exercise, called Teaching Squares as presented by CELT, is
for beginner higher education teachers to gain experience from each other.
Since much of this class is experimental in its design, any anonymous feedback
about what is and isn't working for you is appreciated.
Please use
this anonymous qualtrics survey to give earnest feedback to the instructors at any time.
Accessibility and Reasonable Accomodation
Please let us know as soon as possible if you are in need of any
accomodation to enable you to participate in this course.
To formally request a reasonable accomodation, please use the
appropriate link on
this menu provided by the Office of Equal Opportunity.
Diversity and Inclusion Statement
We strive to create a learning environment for our students that supports a
diversity of thoughts, perspectives, and experiences, and honors your identities.
Please let us know of any accomodation that makes you feel more comfortable
simply existing in the space or communcating with others in the class (e.g.
nametags with preferred pronouns for getting to know each other).
We are all still learning both technically and socially; if something occurs in class that makes
you feel uncomfortable, please talk to us about it (after class, in office hours,
anonymously via the department admins, etc.).
If you prefer to speak with someone outside of the course,
Tufts' Office of Equal Opportunity is
in the fourth floor of 196 Boston Ave. or the
Student Affairs / Student Life Review Committee would be great resources
for you to find someone to talk to.
Lastly, as this is a design course, this course is a great opportunity for you to
express yourself or help your community in a new way. If you would like assistance
making more personal design ideas a reality, please ask us and even if we cannot help
you directly or are not part of that community or identity, we will do our best to
connect you to someone that can.