Common LISP macros
August 27, 2007
Like probably most developers of my age, I haven't learned LISP at school nor used it for anything more than hacking .emacs file.
But I have heard of LISP. Sometimes in horrified tones ("parenthesis hell!", "gives me headache!") but most often with awe and from people whose opinion deserve respect.
After reading Paul Graham's book "Hackers and painters" I felt an increased curiosity about LISP and purchased Peter Seibel's "Practical Common Lisp". I recently had a 2 week vacation and started reading it.
My first reaction was a kind of surprise: I did knew a bit of LISP! The pocket computer I learnt to program with some 20 years ago, a Hewlet Packard 48 (HP48), was a kind of LISP machine. Not so surprising in fact considering how widespread LISP was in the 80s.
The familiarity stopped there. My HP48 is a piece of computing history, while Common LISP is a fully matured language with features that leave me dreamy. Macros to name only one.
I can relate to my own experience with Perl.
Perl is a fairly advanced language. It has closures, higher order functions, evals, threads, introspection and more. Lately I have been trying to extend Perl's syntax to support a form of programming by contract. I started implementing that by using dynamic code generation: letting programs self-modify during runtime. It can be done with Perl, but it requires a rather heavy blend of evals, string manipulation or even opcode-tree hacking (for the hardcore suicide candidates) and ends up being clumsy and limited. Recently I have been trying source filters to help on the way.
In LISP, I could have done that quite simply with macros.
Source filters are the closest equivalent to LISP macros that perl offers. Yet, there is a significant difference between them: LISP macros manipulate LISP code that is already expressed in a form that makes it easy to manipulate by other LISP code (those so-called S-expressions). The perl code of a perl source filter manipulates other perl code in the form of a string of characters. A perl source filter does not understand perl code, which makes the act of altering the source quite hard since all parsing knowledge has to be built into the source filter. And it is wellknown how hard perl is to parse... To gain the full strength of Common LISP macros, perl would need a mechanism for interpreted perl code to self modify itself. There is since recently a CPAN module for parsing perl from within perl: PPI. I wonder how that could be combined together with source filters in order to get closer to LISP macros...
This book is amazingly well paced by the way, and should stand as an example for anyone writing programming language books. It is available online: www.gigamonkeys.com/book/
But I have heard of LISP. Sometimes in horrified tones ("parenthesis hell!", "gives me headache!") but most often with awe and from people whose opinion deserve respect.
After reading Paul Graham's book "Hackers and painters" I felt an increased curiosity about LISP and purchased Peter Seibel's "Practical Common Lisp". I recently had a 2 week vacation and started reading it.
My first reaction was a kind of surprise: I did knew a bit of LISP! The pocket computer I learnt to program with some 20 years ago, a Hewlet Packard 48 (HP48), was a kind of LISP machine. Not so surprising in fact considering how widespread LISP was in the 80s.
The familiarity stopped there. My HP48 is a piece of computing history, while Common LISP is a fully matured language with features that leave me dreamy. Macros to name only one.
I can relate to my own experience with Perl.
Perl is a fairly advanced language. It has closures, higher order functions, evals, threads, introspection and more. Lately I have been trying to extend Perl's syntax to support a form of programming by contract. I started implementing that by using dynamic code generation: letting programs self-modify during runtime. It can be done with Perl, but it requires a rather heavy blend of evals, string manipulation or even opcode-tree hacking (for the hardcore suicide candidates) and ends up being clumsy and limited. Recently I have been trying source filters to help on the way.
In LISP, I could have done that quite simply with macros.
Source filters are the closest equivalent to LISP macros that perl offers. Yet, there is a significant difference between them: LISP macros manipulate LISP code that is already expressed in a form that makes it easy to manipulate by other LISP code (those so-called S-expressions). The perl code of a perl source filter manipulates other perl code in the form of a string of characters. A perl source filter does not understand perl code, which makes the act of altering the source quite hard since all parsing knowledge has to be built into the source filter. And it is wellknown how hard perl is to parse... To gain the full strength of Common LISP macros, perl would need a mechanism for interpreted perl code to self modify itself. There is since recently a CPAN module for parsing perl from within perl: PPI. I wonder how that could be combined together with source filters in order to get closer to LISP macros...
This book is amazingly well paced by the way, and should stand as an example for anyone writing programming language books. It is available online: www.gigamonkeys.com/book/
