Poor man's macro programming in php

Jonnay's post I mentioned before started me thinking - what do you need to have macros in php. 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: macro delay() { match { delay( $func, ... ) } : { $varname = $func . random(); $$varname = array(new promise( $func, ... ), 'evaluate'); return $varname; } match { $func( ... ) } : { return call_user_func($$varname, ... }; } }

This looks kind of allright, phpish. It has problems, but the above dream code demonstrates the idea enough - match the left-hand-side code and substitute it with the right hand side. The difference from C macros is that this macro is a program fragment/function/..., the result of which is substituted in the AST, as opposed to simple string pattern matching + substitution

What can be achieved today - well, a lot. "generic functions" and friends can help. In fact, in my opinion, they are the poor man's macros for php. The syntax can end up being ugly. In most of my design pattern collection the code is wrong for that particular reason - it is ugly. But still with the help of call_user_func (the ugliness I mentioned) we can do it even now. The biggest difference is the time when the code is transformed and the possible tradeoffs between execution speed vs compilation speed

I'm glad I am not the only

I'm glad I am not the only Schemer working with PHP...

I like your syntax for pattern patching macros, it really is quite extensible, so one could add other macro processors to the mix. The real question is how to maintain hygiene... if this is even possible.


Well, the way php stands at the moment, hygiene shouldn't be a big issue. If a macro system of this kind is implemented in php, it should inherit the php scoping conventions, meaning that one should be able to see only the locally defined variables, the ones explicitly imported from the global scope and the super globals.

Still, you are right that at the place of substitution name collisions can occur, so probably the solution could be the generation of unique names/symbols at compile time for anything defined inside a macro.

Powered by Drupal, an open source content management system