Re: class notes for Lua course based on PiL

On Sat, Oct 5, 2013 at 5:04 PM, Fabio Mascarenhas <mascarenhas@acm.org> wrote:

Your course looks interesting! I am a fan of the interpreter approach to teaching programming language concepts myself, and have taught two courses with that approach, using PLAI, with one using Racket as implementation language, and the other using the functional parts of Scala. I noticed that this is the first time you are using Lua in this course, may I ask why you picked Lua?

(-: It seemed like a good idea at the time. :-)

This is the first time I have attempted to do an interpreter-based programming languages course. (But I have taught Scala-based and Ruby-based courses with significant domain-specific language components.) I am exploring some ideas this semester in a graduate course and, if it works, tentatively plan to try something similar in our core undergraduate programming languages course this time next year (which I only taught once previously in 1995).

The "in-print" books that take the interpreter-based approach are Krishnamurthi's PLAI and Friedman's Essentials of Programming Languages. I considered using Racket/Scheme and PLAI. But I am not a huge fan of Scheme and suspect that it would not be well received by the students, especially the undergrad students next year.

There is also Sam Kamin's out-of-print 1990 book where the interpreters are in Pascal (or C)--with versions of the interpreters in C++ by Tim Budd. For a few years, I have been toying with the idea of trying to adapt what Kamin did for Scala. I really like Scala and use it in other graduate courses, but it is relatively complex and takes time to get students to the point where they can do much with the language. I decided, instead, to give Lua a try.

My first Lua programming effort after "hello world" was to try to develop Kamin's interpreters. I got more or less working versions of his core, Lisp, and Scheme interpreters and did some planning for a SASL interpreter. (But I need to some redesign and refactoring.) I have yet worked with those in my course, but plan to shift to that over the next week or so.

Why Lua? It is something new for my students (which I wanted), but something that seemed simple enough for them to learn quickly (which I also wanted). It is simple, but it has powerful concepts like closures, metatables, coroutines, etc. to enable interesting programs. Its mechanisms over policy approach seemed to support illustrating to students how to build features. LPEG seems to work well enough. Perhaps metalua would allow touching on compile-time

Writing parsers in LPEG is easy, but making the parsers output nice error messages when syntax errors happen can be tricky. I have a student that wrote a set of functions on top of LPEG that help write parsers with basic error reporting, I will ask him to send you a link.

Thanks.