CS 589: Special Topics in Programming Languages – Modularity (Spring 2017)

Instructor: Eric Walkingshaw ()
TA: Chao Peng (pengc)
Class Time: TTh, 4:00–5:20, Hovland 202 (map)
Office Hours: W, 11:00–1:00, KEC 3049
Piazza: CS 589 on Piazza (Use of Piazza)

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 three 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 supplementary papers 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 two supplementary papers during the course and provide a discussion document for another two supplementary papers.

  • Homework and project workshops – There will be a small number of programming assignments and also two medium sized programming projects during the course. We will spend some time in class peer critiquing each others work in groups of 3-4.

  • Project presentations (time permitting) – Each project team will give a brief in-class presentation of their projects, focusing on how they apply insights and ideas from the course.

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.

  • 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 4

Course introduction

HW: Introduce yourself (due: Apr 6 @ noon)
Apr 6

Introduction to Standard ML

SML vs. Haskell, Expr.hs, expr.sml
Apr 11

Parnas, On the Criteria to be Used in Decomposing Systems into Modules, CACM 1972

HW: Project 1

(Discussion leaders: Alex, Mike, Jeff)
Apr 13

Liskov and Zilles, Programming with Abstract Data Types, ACM SIGPLAN Notices 1974

regexp.sml

(Discussion leaders: Sara, Shivani, Ming-Hung)
Apr 18

Stevens, Myers, and Constantine, Structured Design, IBM Systems 1974

order.sml, sort.sml

(Discussion leaders: Xiaofei, Xichang, Tien-Lung)
Apr 20 No Class!
Apr 25

Cook, On Understanding Data Abstraction, Revisted, OOPSLA 2011

DataTypeObjects.hs, TypeClassObjects.hs

(Discussion leaders: Dafu, Jishen, Menglin)
Apr 27

Kästner, Apel, and Ostermann, The Road to Feature Modularity, SPLC 2011

(Discussion leaders: Chenxi, Bei, Zhiyong)
May 2

Harper and Pierce, Design Considerations for an ML-Style Module System, from Advanced Topics in Types and Programming Languages, 2005
Sections 8.1–8.4

Modular PCF

(Discussion leaders: Nicholas, Zihang, Xiaobo)
May 4

Harper and Pierce, Design Considerations for an ML-Style Module System, from Advanced Topics in Types and Programming Languages, 2005
Section 8.5, The Pragmatics of Functors from 8.8

(Discussion leaders: Ameya, Jeff, Alex)

Supplementary papers

  • Aldrich, The Power of Interoperability: Why Objects are Inevitable, Onward! 2013.
  • Ostermann et al., Revisiting Information Hiding: Reflections on Classical and Nonclassical Modularity, ECOOP 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 9

Introduction to the Expression Problem
Wadler, The Expression Problem, email 1998

Arith.hs, ArithFinal.hs, Arith.java, ArithVisitor.java

(Discussion leaders: Yanxin, Ming-Hung, Shivani)
May 11

Lämmel and Ostermann, Software Extension and Integration with Type Classes, GPCE 2006

MonoidClass.hs, MonoidDict.hs

(Discussion leaders: Mike, Xiaofei, Tien-Lung)
May 16 No Class!
May 18

Findler and Flatt, Modular Object-Oriented Programming with Units and Mixins, ICFP 1998

TaglessFinal.hs
See Oleg Kiselyov’s page for much more info on tagless-final encodings

(Discussion leaders: Xichang, Sara, Jishen)
May 23

Swierstra, Data Types à la Carte, JFP 2008

HW: Project 2
AlaCarte.hs, Prim.hs, Cond.hs, PCF.hs

(Discussion leaders: Menglin, Dafu, Bei)
May 25

Oliveira and Cook, Extensibility for the Masses: Practical Extensibility with Object Algebras, ECOOP 2012

(Discussion leaders: Xiaobo, Chenxi, Zhiyong)
May 30 No Class!
Jun 1

Clifton et al., MultiJava: Modular Open Classes and Symmetric Multiple Dispatch for Java, OOPSLA 2000

BinaryMethod.hs

(Discussion leaders: Yanxin, Nicholas, Zihang)
Jun 6

Löh and Hinze, Open Data Types and Open Functions, PPDP 2006

polyvar.ml

(Discussion leaders: Ameya, Shivani, Sara)
Jun 8

Janzen and De Volder, Programming with Crosscutting Effective Views, ECOOP 2004

(Discussion leaders: Xiaobo, Yanxin, Zhiyong)

Supplementary papers

  • Carette, et al., Finally Tagless, Partially Evaluated: Tagless Staged Interpreters for Simpler Typed Languages, JFP 2009. `#DesignPattern #FP
  • Krishnamurthi et al., Synthesizing Object-Oriented and Functional Design to Promote Re-Use, ECOOP 1998. #NewLanguage
  • Axelsson, A Generic Abstract Syntax Model for Embedded Languages, ICFP 2012. (Builds on Data Types à la Carte.) #Library #FP
  • Palsberg and Jay, The Essence of the Visitor Pattern, COMPSAC 1998. #Library #OO
  • Zenger and Odersky, Extensible Algebraic Datatypes with Defaults, ICFP 2001.
  • Zenger and Odersky, Independently Extensible Solutions to the Expression Problem, FOOL 2005.

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.