Artagnon's Presence

I thought the “Haskell Internals” talk was probably too technical. I expected a lot of people to have some prior exposure to functional programming. Otherwise the Haskell code dump would have shocked them. @swaroopch told me that my “An Insight into CPython Compiler Design” (it’s called unladen-swallow.pdf here) was good, mainly because I made it clear what I’m going to be talking about in the title. @NOLFXceptMe told me that the talk was super-informal, like I was explaining to someone across the coffee table- exactly what I intended! It has a LOT of C code, but that didn’t scare people one bit. I could tell from the feedback session that many of them actually read the code, unlike the Haskell code from my previous talk. Anyway, lesson learnt. Here are the slides. You can get the sources and compile it for yourself with notes, or just see the BiBTeX references here. Oh, and the comments section in the blog exists for a reason- I want feedback! I can’t improve without it.

haskell-internals.pdf (504 KB)

unladen-swallow.pdf (644 KB)

A couple of my talks have been shortlisted, but the abstracts won’t be up on the site until a week before the conference. So here are the abstracts. I’ve just started preparing the talks, so feedback is appreciated.

An Insight into CPython Compiler Design

The objective of this talk is to give the audience an insight into compiler design, specifically the design of the CPython compiler. The talk attempts to do this by taking apart the Unladen Swallow codebase.

Starting from a small hand-waving discussion using block diagrams, we will discuss compiler optimization techniques introduced by Unladen Swallow using revision control to playback changes. There is (and will be) no original research; only implementation of ideas from existing research papers.

A significant portion of the talk will be dedicated to compiling Python bytecode to LLVM IR (in Python/llvm_compile.cc), and the eval loop (in Python/eval.cc). While there are thousands of possible optimizations, only those which yield significant benefits and are in line with CPython’s objectives will be discussed.

Intended audience: Programmers interested in understanding (and ultimately contributing to) compiler projects like Clojure, Unladen Swallow, GHC.

Prerequisites: Requires a basic understanding of language grammers and parsing [1], as well as elementary compiler design [2]. The talk will jump right into the codebase with little introductory material, so the audience is required to do a little background reading.

[1] Flip through the relevant parts of the Dragon Book
[2] Scheme’s eval-apply loop from SICP should do fine

Haskell Internals

The session will focus on writing clever code in non-monadic Haskell, by solving several problems modeled on problems in [http://projecteuler.net] and [code.google.com/codejam/]. It will serve as an introduction to folds, maps, laziness, lexical closures, and other core features of functional programming in Haskell, while also attempt to give a small peek into the working of the Glasgow Haskell Compiler.

Target audience: People interested in functional programming and people interested in scientific computing.

Prerequisites: Ideally none. But since  the session intends to have little introductory material, a quick read through some jargon will be necessary.

This course attempts to teach programming methodology from an engineering viewpoint, as well give an insight into theoretical computer science.

Guidelines:

1. Teach programming, and not the programming language. Discuss abstract ideas in class, and ask students to write implementations in a language of their choice. Avoid building language-specific patterns (for example, the double-for loop for generating prime numbers in C got stuck in my head). Discuss various different implementations AFTER the students have tried it themselves.
2. Discussions should span several programming paradigms. Initially, cast problem statements to strongly indicate a paradigm. For example “Go over numbers from 1 to 10 and print those that are even” versus “Define an even number and print even numbers <= 10″. Later, let students figure it out themselves.
3. Develop a hacker mindset- give students incomplete solutions written by other students and ask them to complete it.
4. For routine assignments, prepare a huge problem set of ascending difficulty to randomly pick from, along the lines of Project Euler. Problems should cover algorithms, pure math, computational geometry, and dynamic programming.
5. Conduct collaborative programming sessions where students learn to implement from each other. No single instructor will be able to provide such a vast variety of implementations.
6. Prepare a reading list for software engineering, including articles on editing (introduction to specialized editors such as Vim and Emacs), debugging, versioning, testing, and profiling. It’s important to make students write large programs collaboratively in steps, so that they will be able to appreciate the importance of these tools.
7. Prepare another reading list for theoretical computer science. Also give students sneak peeks into the latest work in every field. The purpose of this exercise is to get students excited, so that they can work independently to eventually discover their research interests.
8. Finally, it all boils down to grading. If you’re going to ask students to evaluate things like (i++) + (++i) in the exam, it’s clear that you’re expecting students to know programming language intricacies, and not programming methodology.

lecture1.pdf (130 KB)