LISP macros versus C macros

Ted Neward also laments the lack of LISP-style macros in mainstream programming languages. Damn straight. LISP macros allow you to extend the syntax of your programming language. You know how modern IDEs allow you to type ‘for’ and then hit some key and it expands into a complete for loop and even knows, within the generated code, where the “blank spots” are that you need to fill in, and even moves the cursor to where you start typing in (in Visual Studio 2005, these are called “snippets”)? So if you had a snippet/macro that generated, let’s say, the scaffolding to instantiate a DirectX surface and another snippet that generated the scaffolding to, say, load a mesh and add it to the surface, your typing might be reduced to “GameSurface{expand-key} LoadMesh{expand-key}room.mesh;” and you might end up with 1,000 lines of code and you’d code before and after and in the “blank spots” with your normal coding language. Now imagine that the expansion of the snippet occurred at compile or runtime. So you’d have a whole bunch of normal programming code, but in the middle, instead of 1,000 lines of code, you’d just have “`GameSurface `LoadMesh room.mesh” and the back-quote (say) would indicate “expand this.” And, of course, it might be hard at first for someone to understand what goes on when GameSurface or LoadMesh is expanded. But once they were convinced that it was robust and flexible, they’d probably start using the LoadMesh snippet/macro themselves and, in doing so, would be using what is in effect a Domain-Specific Language. And, of course, it’s hard to write a robust and flexible snippet/macro. But it’s still simpler than any other way I’ve seen to write DSLs.

Uh… Now that I think about it… With today’s VS2005 macro capabilities, could you write a macro that expands other macros and then run the “expanding” macro as a custom pre-build step? Gee, how much more would I like to explore that this weekend than debugging the dang broken permalinks on my site?

>