>>49
It's fairly simple in concept. Since macros don't evaluate their parameters, you can make a form like (perl $foo=3 ... ) expand to whatever, by parsing the symbols given as parameters to the perl macro (defmacro perl (&whole code) ... ).
Of course, the tricky bit is that such a macro definition will just give you a bunch of symbols like the above "$foo=3". You can make the situation a little bit better by stipulating spaces wherever possible ("$foo = 3"), but you're still stuck doing pattern matching on symbols for variable names (owing to sigils and such), which means you'll probably be treating them as strings and losing the ability to do simple backquote substitution of symbol values into literal text forms:
(defmacro mact (name val)
`(let ((,name ,val))
(print ,name)))
(macroexpand-1 '(mact foo 3))
(LET ((FOO 3))
(PRINT FOO))
Basically, parsing something like perl code with a macro is pretty much akin to parsing it as plain text. Macros are great if you're implementing a language with no semantic content in its symbols, meaning that any given symbol either has a known meaning or is a new name for something, but when a given symbol may be a name and a programmatic instruction, it gets tricky fast. Take a look at the source for your favorite Lisp's loop macro and you'll see that, even when the language to be parsed is simple, constructing working code out of it is pretty hairy (1k - 2k LOC hairy).
On the plus side, if I were writing a parser for something Lisp would be more fun than C or something to write it in.