CS 589: Special Topics in Programming Languages – Modularity (Spring 2019)
| Instructor: | Eric Walkingshaw () |
| First Mate: | Jeff Young (youngjef) |
| Class Time: | TTh, 12:00–1:20/1:50, Weniger Hall 287 (map) |
| Office Hours: | After class and Fri, 11:00–12:00, KEC 3049 |
| For the project push: Tues, 1:30–3:30, Jeff in the Atrium |
Course Description
Modularity and abstraction are the keys to scaling software to tackle large and complex problems. At a very high level, modularity means to break a complex system down into smaller parts, and abstraction means to generalize something to make it reusable. In this four-credit special topics in programming languages course, we’ll explore these concepts in much more depth.
The high-level goals of the course are to:
- Develop nuanced understandings of the concepts of modularity and abstraction, why they’re important, and how they can be achieved.
- Survey programming language features to support modularity in both a functional and object-oriented setting.
- Study the ML module system in depth, practice using it, and implement a simplified version of it.
- Understand the challenge of extending modular systems.
- Explore and practice using several different language features and design patterns to support modular extensibility.
The course is targeted at advanced students of programming languages, especially those doing research in programming languages or related areas. CS 581 (Programming Languages I) is a prerequisite and CS 582 (Programming Languages II) is recommended. We will use a variety of programming languages throughout the course so you should be comfortable picking up the basics of new languages quickly. I will assume you know Haskell well and also have a working knowledge of statically typed object-oriented programming (e.g. Java).
This course is highly interactive, so it is vitally important that every student feels safe and welcome to contribute. Please read this community statement and let’s work together to make this a great environment for everyone.
Format of Course
Although there will be some lectures and live coding, this is not a lecture-oriented class. It will instead emphasize active learning. That is, you will do preparatory work outside of class and then we will share, discuss, and critique these efforts during our in-class time together. The philosophy of the course is that you learn best by actively doing, discussing, and teaching, but this only works if everyone buys in.
Class time will consist of the following kinds of activities:
Lectures and worked examples – Just bring your brain and I’ll try to fill it up. :-)
Core paper discussion groups – For each of the core papers, we will split into two discussion groups. Each group will be led by a discussion leader. Every student will read each core paper before class and submit a brief discussion document to help the discussion leader prepare (see Deliverables). In addition to analyzing the paper and answering questions, each discussion group will produce a brief summary document as output. At the end of the discussion groups, we will reconvene as a class to answer questions and summarize the results.
Supplementary paper presentations – To get a broader perspective, students will also choose and present a supplementary paper to the rest of the class. Each paper will be presented by a group of 2-3 students and read by 2-3 additional students who will provide discussion documents to the presenters to help them prepare. Each student will present one supplementary paper during the course and provide a discussion document for another supplementary paper.
Homework and project workshops – There may be 1-2 small programming assignments and there will definitely be a final project. We will spend some time in class peer critiquing each others work in groups of 3-4.
See also:
Deliverables – An overview of the kinds of deliverables you will submit and when. Includes the format and deadline of discussion documents and summary documents.
Final Project – Guidelines and deliverables for the final project.
Grading and Homework Policy – How grades will be computed and course policy on out-of-class work.
Links and Useful Resources – Lots of background and supplementary reading material.
Schedule and Reading Assignments
The course can be roughly organized into two parts, which are described below.
Part 1: Modularity and abstraction
We will start by reading some general papers on modularity and abstraction, and by looking at how modularity is supported by a variety of programming languages. Our goals will be to identify underlying principles that make modularity possible and effective, to extract corresponding properties that a module system should enforce, and to analyze whether and how these principles are supported by existing languages.
We will also study in depth the ML module system, which is notable for being particularly expressive and carefully designed. We will consider how the ML module system supports the principles we identify in our readings, practice using it, and consider how to implement a simplified version of it.
| Apr 2 |
Course introduction and introduction to Standard ML SML vs. Haskell, Expr.hs, expr.sml HW: Introduce yourself (due: Apr 5 @ 5pm) |
| Apr 4 | Parnas, On the Criteria to be Used in Decomposing Systems into Modules, CACM 1972 |
| Apr 9 |
Liskov and Zilles, Programming with Abstract Data Types, ACM SIGPLAN Notices 1974 Stack.hs, StackClient.hs |
| Apr 11, 16 |
Stevens, Myers, and Constantine, Structured Design, IBM Systems 1974 queue.sml |
| Apr 18 |
Cook, On Understanding Data Abstraction, Revisted, OOPSLA 2011 DataTypeObjects.hs, TypeClassObjects.hs |
| Apr 23 |
Harper and Pierce, Design Considerations for an ML-Style Module System, from Advanced Topics in Types and Programming Languages, 2005 |
| Apr 25 |
Harper and Pierce, Design Considerations for an ML-Style Module System, from Advanced Topics in Types and Programming Languages, 2005 |
| Apr 30 |
Ostermann et al., Revisiting Information Hiding: Reflections on Classical and Nonclassical Modularity, ECOOP 2011 InClassMonoidClass.hs, MonoidClass.hs, MonoidDict.hs Paper presentation: Parnas, On the Design and Development of Program Families, TSE 1976 |
| May 2 |
Ostermann et al., Revisiting Information Hiding: Reflections on Classical and Nonclassical Modularity, ECOOP 2011 Paper presentation: Kästner, Apel, and Ostermann, The Road to Feature Modularity, SPLC 2011 |
Part 2: Modular extensibility
A property of good software is the ability to add new features in a modular way. That is, it should be possible to (1) add new features without making invasive changes to the existing code, and (2) keep the code that implements each new feature together. Modular extensibility makes software more maintainable by keeping separate concerns separated in the code; it increases flexibility by making software easier to extend in new and unforeseen ways; and it supports customizability by making it easier to add and remove features according to the needs of different users.
Many programming languages provide good support for some kinds of modular extensions but not others. Most significantly, object-oriented languages and functional languages support modular extensibility in orthogonal dimensions. The challenge of supporting all kinds of modular extensions has been called the “expression problem” or the “tyranny of the dominant decomposition”.
In this part, we will study modular extensibility, focusing especially on the design patterns and language features that address the expression problem.
| May 7 |
Introduction to the Expression Problem ArithVisitor.java, ArithFinal.hs Paper presentation: Aldrich, The Power of Interoperability: Why Objects are Inevitable, Onward! 2013Presenters: Qiulin and Yiting Discussants: Ghadeer, Yi, Zhaobang |
| May 9 |
Lämmel and Ostermann, Software Extension and Integration with Type Classes, GPCE 2006 Paper presentation: Palsberg and Jay, The Essence of the Visitor Pattern, COMPSAC 1998Presenters: Yi, Zhaobang Discussants: Qiaoran and Linhan |
| May 14 |
Findler and Flatt, Modular Object-Oriented Programming with Units and Mixins, ICFP 1998 TaglessFinal.hs, see also: Oleg Kiselyov’s page on tagless-final encodings |
| May 16 |
Swierstra, Data Types à la Carte, JFP 2008 AlaCarte.hs, Prim.hs, Cond.hs, PCF.hs, |
| May 21 |
Catch up day! |
| May 23 |
Project proposal workshops polyvar.ml |
| May 28 |
Oliveira and Cook, Extensibility for the Masses: Practical Extensibility with Object Algebras, ECOOP 2012 |
| May 30 |
Clifton et al., MultiJava: Modular Open Classes and Symmetric Multiple Dispatch for Java, OOPSLA 2000 Paper presentation: Kiselyov, Typed Tagless Final Interpreters, Section 3 |
| Jun 4 |
Project milestone workshops Paper presentation: Zenger and Odersky, Independently Extensible Solutions to the Expression Problem, FOOL 2005 |
| Jun 6 |
Löh and Hinze, Open Data Types and Open Functions, PPDP 2006 Paper presentation: Janzen and De Volder, Programming with Crosscutting Effective Views, ECOOP 2004 |
Supplementary papers
- Carette, et al., Finally Tagless, Partially Evaluated: Tagless Staged Interpreters for Simpler Typed Languages, JFP 2009
- Kiselyov’s work on tagless-final encodings
- Krishnamurthi et al., Synthesizing Object-Oriented and Functional Design to Promote Re-Use, ECOOP 1998
- Axelsson, A Generic Abstract Syntax Model for Embedded Languages, ICFP 2012 (Builds on Data Types à la Carte.)
- Zenger and Odersky, Extensible Algebraic Datatypes with Defaults, ICFP 2001
Accommodations for Students with Disabilities
Accommodations for students with disabilities are determined and approved by Disability Access Services (DAS). If you, as a student, believe you are eligible for accommodations but have not obtained approval please contact DAS immediately at 541-737-4098 or at http://ds.oregonstate.edu. DAS notifies students and faculty members of approved academic accommodations and coordinates implementation of those accommodations. While not required, students and faculty members are encouraged to discuss details of the implementation of individual accommodations.