Topics

programming

php drupal scheme scheming macros design patterns da la

design

design css

random thoughts

scribbles

alter ego

other me 'em that link us my space me linked in

Collections

Programmable web
PHP design patterns

Similar things

  • macros, higher-order functions, datatypes and design patterns
  • macro processor - initial notes
  • Emulating closures in PHP
  • Some ways to use saved state with closures in php
  • Poor man's macro programming in php (revisited)
  • Rewriting macros - the peculiar case of php
  • A pause for thought and some cut backs
  • scheming templates
  • scheming away
  • still scheming away

guild
Home » blogs » vlado's blog

Poor man's macro programming in php

Submitted by vlado on Wed, 2006-07-26 15:43.macros | php | programming | scheme
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

vlado's blog | add new comment
I'm glad I am not the only
Submitted by jonnay (not verified) on Wed, 2006-07-26 22:14.

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.

reply
hygiene
Submitted by vlado on Thu, 2006-07-27 09:03.

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.

reply
Home » blogs » vlado's blog

dikini.net

spreading confusion by accident since 1970