Without going into theoretical details, some of which are quite alien to me, I'll try to describe some of the challenges that pattern patching rewriting macros might pose for a language like php. After brief explanation what kind of a beast is this, I try to explore some of the finer points, which might cause problems. The intent of this post is to sketch a design and highlight some of the possible issues.

He breaks up the post into a few sections:

• pattern matching rewrite only macros - a bird eye view
• Transformation time
• Basic/skeleton shapes and intermediate shapes
• Code generation issues specific to php
• Hygiene
• A rough macro shape outline
• Output/Status of the project

Macros have (let's say) two main responsibilities - adding syntactic sugar and abstraction of common patterns. The syntactic sugar bit is something which probably should happen at compile time, at least in a weakly typed language like php. So I'll skip them. The abstraction of computation, well this is wat codified design patterns are.

He illustrates what a macro might look like, using the generic functions and partial evaluation patterns to accomplish it. He also shows it being possible with something built around a create_function call.

So what do these example prove? Well, php has decent abstraction mechanisms. The fact that we can do indirect function calls and indirect variable (symbol) resolution can give us useful means to code in different design patterns. How can we make proper macros? Is it too complicated to have something like dylan macros (a nice paper from 1999)

What is the closest we can get to that without actually changing anything in php (poor man's version? What minimal sugar does php need to make it comfy? What is the natural syntax for macros in php? I definitely don't know the answers to these questions but let's try.

He doesn't create working code, but he does make it a PHP-ish looking solution. He also suggests that while PHP doesn't have this ability (yet?), the generic function pattern can help mimic its functionality pretty closely.

This (as described) sounds exactly like a rewrite of the C preprocessor, which one can work with fairly easily in a PHP environment. To see this duplication of effort on something so boring and useless makes me question just how much PHP is its own language, versus a Frankensteins monster of language clones; see PHP 5's object system for a perfect example.

He comments that maybe the developer should have come up with a different way to do it instead of making what appears to be a sibling of the current processor. He also suggests that PHP developers step up and create methods for the current compiler to make using things like design patterns much simpler than they currently are.