by sindoc on 8/24/11, 11:22 PM with 16 comments
by rpearl on 8/25/11, 1:39 AM
While we have a thorough curriculum on functional programming at CMU (and for one class I did write several compilers which took more complex languages and translated them to the lambda calculus and even more minimalistic languages like the SK (optionally I) combinator calculus, that class wasn't on compilers, it was "Principles of Programming Languages". It also covered type theory, implementing type inference, and so on.
Whereas our compilers class covers the sort of topics you would expect in a compiler targeting a real architecture: parsing/lexing, choosing intermediate languages, SSA form, optimizations, register allocation, code generation, and so on. We have a separate class which covers compiling higher order typed languages (SML in particular).
Our compilers class is also unusual (in ones I have seen) in that, instead of building a lexer, building a parser, doing translation, and so on for each stage, as separate projects, rather students build a whole compiler for each assignment. The language compiled gains more and more features: first control flow, then function calls, then memory operations (structs, arrays, heap-allocation).
Might I ask your thinking when choosing the lambda calculus as the basis for your compilers class?
by russellallen on 8/25/11, 12:48 AM
Perhaps we're all afraid of looking stupid... easier to discuss Job's retirement or something less scary :)
Anyway, to drop down a metalevel, this is fabulous but also interesting for what the lambda calculus doesn't talk about - concurrency and more broadly time. I'd like to see more pages like this but which come from an actor model of computation or some other process calculus.
by DanielRibeiro on 8/25/11, 3:26 AM
[1] http://math.ucr.edu/home/baez/rosetta.pdf , pg55