CSC 530, Spring 2012
WAIT! I haven’t rewritten this text yet! Don’t read it!
...
"Those who cannot remember the past are doomed to repeat it" – George Santayana
This notion is particularly applicable in Programming Languages research, where newcomers continue to re-invent the wheel over and over and over and over. In fact, an old PL saw suggests that it takes about 30 years for PL research to make it into the mainstream. So, a look into the past of PL research is a look into the future of mainstream computing.
Accordingly, we’ll start out by looking into the past of PL research, reading a number of papers from the distant past whose lessons have yet to be sensibly adopted. We’ll move on from here to take a look at current research.
1 Outcomes
build simple models of programming language semantics, and
see how these models relate to the languages you use every day.
2 Prerequisites
This is an upper-level course in programming languages, and assumes a familiarity with the principles of programming languages, including but not limited to notions of scope, calling convention, evaluation rules, compound data, and basic typing.
Additionally, students are assumed to have a basic understanding of simple mathematics, including the basics of set theory, very simple algebra, and some experience with proofs and basic mathematical rigor.
Finally, it requires curiosity, and self-driven exploration.
3 Names, Times, Locations
Google Calendar:
See my Cal Poly Home Page for my calendar, including times & locations of labs, lectures, and office hours. You can add it to your calendar, if that makes your life easier.
3.1 Instructor
John Clements, aoeuclements @ brinckerhoff.org
3.2 Lecture & Lab
Lecture: 1400-1600, M/W, room 014-232B
3.3 Web Page
This is the course web page, its link is http://www.csc.calpoly.edu/~clements/csc530-sp12/.
4 Computing Environment
The bulk of the programming in this course will probably be in various flavors of DrScheme: Scheme, Redex, Typed Scheme, etc. We may detour out to Haskell just for laughs.
You’ll want to use version 4.1.5, released just a few weeks ago. You can download it from
5 Readings
Some of the readings will be from papers. Some will be from the monograph.
Here’s a partial list:
The Felleisen-Flatt Monograph: this will be the closes thing we have to a textbook. It’ll basically serve as lecture notes for many of our class sessions.
6 Communication
This class will use Piazza. This will be the principal means that I’ll use to notify you of deadlines, organizational updates, and changes to assignments. If you’re not keeping up with the group, you’re going to be missing important information.
It’s also the best way for you to direct questions to me and/or the class. Feel free to e-mail me with personal questions, but use the Piazza group as your main means of communications. It’s possible to post anonymously, if you like.
You should already have received an invitation to the Piazza group; let me know if you need an invite.
Don’t post your code or test cases to the group; anything else is fair game.
Also, please keep in mind that I (and everyone else) judge you based in part on your written communication. Spelling, complete sentences, and evidence of forethought are important in all of your posts & e-mails. One easy rule of thumb: just read over what you’ve written before clicking post or send, and imagine others in the class reading it.
7 Assignments/Milestones
Unless otherwise specified, all assignments are due at 11:00 PM.
7.1 Grading Methods and Expectations
Boilerplate:
I will grade submitted code by running test suites of my own devising and by running your test suites and by reading your code.
I will grade your presentations based on the success of the demonstrated code and upon the delivery of the presentation.
Naturally, all grades contain an element of subjectivity.
8 Attendance Requirements
I do not formally state attendance requirements.
However, an outrageously large fraction of the grade depends on your class participation; if you don’t show up, you’re unlikely to get a good grade.
9 Interacting with the Handin Server
You will be handing in your work in this class using a specialized handin program that communicates with a handin server running remotely. From past experience, there are several things that may not be obvious about your interactions with this server.
I disregard earlier submissions when later ones are improvements. So, for instance, if you get a dialog that offers you a chance to save with a penalty, you need not worry that this penalty will affect you if you resubmit later (as long as it’s before the deadline)
The handin server stores the last five submissions on your account. So, if you’re unsure as to whether the deadline has passed, go ahead and submit; if I decide to disregard the final one, I can take the prior one instead.
10 Cheating
In the programming assignments, you may not copy another team’s code (including test cases and pseudo-code). You may not share code with other teams in the class. That is, you may not allow another team to see the code you write for the class, deliberately or through obvious negligence.
Any code you submit that is attributable to another source must be clearly identified as such. In general, you will not receive credit for code that your team did not write.
I will use an automated tool to compare student submissions and identify cheating.
Students believed to be cheating–that is, both parties involved in the transfer of code–will receive a failing grade in the class.
11 Exams
There will be no exams in this class.
12 Grades
Grades will be determined by performance on programming projects, your paper presentation, and class interaction. A small fraction of the grade is determined by the instructor’s whim.
Assignments: 25%
Class Participation: %40
Paper Presentation: 30%
Instructor’s Whim: 5%
13 Schedule/Homeworks
Did you miss the link at the top of the page?
14 Acknowledgments
Many thanks to Aaron Keen for course materials, including much of the text on this page.