in reply to Overcoming addiction to Lisp

Hmmm. If you think macros are "not necessary in most cases" I'd suggest that maybe you haven't quite grokked The Lisp Way is thouroughly as you might have. If I may humbly suggest that, before you move on, you owe it to yourself to understand what you're giving up, you might want to check out a book aimed at folks like you (who like Lisp or the idea of Lisp but have had trouble actually putting it to use). It's available online at: http://www.gigamonkeys.com/book/ as well as in treeware from Apress. Yeah, I'm biased--I wrote it. But I'm not just a crazy Lisp zealot--back in the day I used to hack Perl full time and even wrote a couple modules for CPAN (including Class::MethodMaker, since adopted by someone else.) -Peter

Replies are listed 'Best First'.
Re^2: Overcoming addiction to Lisp
by Anonymous Monk on Jun 15, 2005 at 21:50 UTC
    • When I program in C, I laugh at those who foolishly squander CPU cycles with their "high level" language constructs.
    • When I program in Fortran, I scoff at those languages who don't handle arrays and parallelism properly.
    • When I program in Perl, I wonder how all those other languages live without regular expressions and CPAN and DWIM.
    • When I program in Lisp, I dismiss anyone who doesn't think macros are like sliced bread.
    • When I program in Scheme, I sneer at anyone who can't write a compiler for their language of choice.
    • When I program in Haskell, I wonder how anyone could think static typing was anything other than the "Right Thing "
    ...and yet I somehow manage to use each of those languages in one way or another. Go figure.
Re^2: Overcoming addiction to Lisp
by Anonymous Monk on Jun 15, 2005 at 22:14 UTC
    Macros can provide cutesy solutions to some problems, and can provide a performance boost if you have an inferior compiler, but I challenge you to give a compelling example of what macros can do, that you couldn't also do (almost as succinctly) with higher order functions in perl. Here's a list of things that I probably won't find compelling...
    1. Yet another implementation of Prolog
    2. functions that don't evaluate their arguments (wrap 'em up in a sub{} closure
    3. ).
    4. a 10% speed boost (Perl's too slow to worry much about speed.
    5. custom made regular expression embedded language (already got it)
      None of these, to me, a new Lisper, are what macros are about. Macros are about being amazingly lazy as a programmer. About finding those patterns of code that you write all the time, and making the system do the work for you in ways that are nearly impossible in other languages. It's not about speed, though certainly macros can be faster, especially if you look at things like the CL regex engine. The point is that I'm lazy, and I don't like typing things, and macros let me say it once, and more succinctly than other things. Lisp isn't the hammer for every problem, nor is Perl, nor is any tool. I don't trust a programmer who things his favorite hammer is the best hammer.
        As an experienced Lisper (and mostly Schemer today) I have used both hygienic as well as non-hygienic (Common Lisp) macros. I'm going to be something of a heretic here, but in nearly every case there is likely something *better* to use than a macro. As an implementor of Scheme i've seen a number of additions that supplement R5RS (or even Common Lisp) that remove just about every need for a macro. A simple builtin function such as LAMBDA-CASE removes the need for just about every Scheme macro in existance. And here is the real kicker... the closer you get to a programmable programming language (what Lisp is known for anyhow), the more odd and almost alien macros become. They almost blend into and become functions themselves, in a way. If this sounds confusing, imagine a Lisp interpreter (or Lisp Machine) that is always running (and evolving.. just like the good old days). Macros *must* become first-class citizens, or they simply don't make sense at all. And, of course, many people have already proposed such additions! In this manner, they aren't much different from functions which are first-class already. And there have even been "lexical macros" which retain source-level information for debugging purposes. Hmm.. I wonder what else can be tied to lexical scope and is first-class.... functions!
        Eliminating reduntant code has more advantages than just laziness. It improves code quality, especially during maitenance.

      Whether you can do something with higher order functions or even simpler constructs isn't a great argument against having macros.

      Recently I needed to do something for every string of length N or fewer. So I wrote a function that returned a closure that enumerated all strings until exhausting the string space. But I had to loop over the string space a few times in the program, and it got really cumbersome to write things like this:

      (flet ((next-string (make-string-enumerator <num>))) (loop for str = (next-string) until (null str) do <body>))

      Once I'd written that twice, I realized that I was eventually going to make mistakes writing or rewriting expressions like that, so I wrote a macro that expanded into that expression. Once I had the macro, I could write the following instead of the above:

      (dostrings (str <num>) <body>)

      Now, maybe you're thinking "That's only a two-line savings in any place where you'd need to do what you're doing", but to me the win is that the macro lets me write only the important things (the <body>, the maximum string length <num>), and the macroexpander takes care of the tedious and error-prone code for me. This isn't just saving typing: I don't have to think up a variable name like next-string whenever I need to loop over all strings, and so I never have to track down bugs introduced by changing variable names when refactoring. If I don't use it outside the macro, I don't even need to remember the purpose or interface for make-string-enumerator, either.

      Yeah, I could have written something analogous to the <body> form as a function of the string returned by the enumerator, and written the original loop like this:

      (let ((next-string (make-string-enumerator <num>))) (labels ((looper (body enumerator))) (let ((str (funcall enumerator))) (when str (funcall body str) (looper body enumerator)))))

      But I'm not sure that's easier to understand than either the original loop form or the dostrings macro, and anyhow it's still long enough that I think I'd want something like my dostrings macro to generate it if I had to write something like that more than once.

      Functions (including higher order functions and closures) are one way of factoring code for maintainability; macros are another. They complement each other.

        Maybe I missed it, but why would dostrings need to be a macro, instead of a function? And if you don't like making up non-sense names, just use perl's default name, $_. Besides, it really sounds like you should be using the builtin list traversal operators like grep, map, and foreach instead of rolling your own.
        What is the special feature about those examples that couldn't have been done just as well (or succinctly, or whatever) without macros?