Lambda the Ultimate

I recently saw an inspiring presentation about how programming frameworks can help software developers, by providing more immediate feedback on the effect of changes to your code and better visualizations to understand what your code is doing. I found it thought-provoking, and I thought others here might, too.

Bret Victor, Inventing on Principle. CUSEC 2012.
http://vimeo.com/36579366

Enjoy!

If you are in Denmark in September you should attend. If not, raise a glass to salute what is now abundantly clear: FPLs are conquering the ("real") world.

Hi all!

I built an interpreter for a language that is similar to lisp and scheme (https://github.com/bryanedds/aml/wiki). I am thinking about writing a .NET compiler for it, however I think I am missing some fundamental background knowledge. I think I can see how it might be smart to write an itermediate 'machine' that indirectly generates IL code rather than manually translating each special form to IL code directly. So instead of going from AST analysis straight to IL, I would go from interpreter to 'hand-wavy-virtual-machine' to IL. This stratification seems like a good idea, as it may ease optimization logic by reasoning about semantics at a lower level, but I don't know where to start.

Is there a typical stratification technique for building compilers for lambda calculus-based languages? It seems like it would look like an intepreter that passes symbolic primitive that are understood by a 'machine' that produces .NET code. Perhaps the SECD machine (http://en.wikipedia.org/wiki/SECD_machine) was something like this? I think Haskell's G-Machine might also be similar?

Am I off-base here?

PS - I'm still a language design newbie, so please keep any answers simple for me :)