As Elian says lisp macros act on the parsed representation of the code. Lisp code is trivial to parse. It is also made up of simple, fundamental lisp data structures. The power of lisp comes from its ability to trivially represent lisp programs as lisp data. This allows you to write programs which write programs, which is very powerful.
Suppose your language lacked a for loop (as in C and perl) but had a while loop. In lisp it would be very easy to implement one as a macro. This macro for loop would be just as efficient as if the language provided one in the first place. This is a fairly trivial example but it might give you an idea. In most languages you just can't do that. Essentially this gives you a 'programmable programming language' (to quote Paul Graham). It lets you extend lisp into a domain specific programming language for whatever domain you want with no loss of speed. A lisp programmer would not tend to use XSLT for transforming XML - they would just extend lisp to implement the same functionality.
Extending perl in this way with source filters (adding bits to the language) would not be easy due to the difficulty in parsing perl. It is possible that the B:: modules could be used to do a similar thing in perl. I'm not sure though. It wouldn't be easy due to the complexity of the parsed perl programs. Interesting thought though.
| [reply] |
Well, if by "one" you mean you, or me, or a very small handful of other people, sure. We can do the same with XS, too--it's still far less safe than Lisp macros, and a bare step above pack "p" and slamming bits directly into memory. It is, however, acting on the final internal representation of the program, rather than on the parsed version of the program. (Though in perl's case there is no actual difference, as there's no 'just parsed' version to manipulate before it gets turned into the structures that get executed) | [reply]
[d/l] |