views:

290

answers:

7

I've heard that Lisp's macro system is very powerful. However, I find it difficult to find some practical examples of what they can be used for; things that would be difficult to achieve without them.

Can anyone give some examples?

A: 

Just a guess -- Domain Specific Languages.

Austin Salonen
This question has a CW feel to it so I posted as such.
Austin Salonen
But what is it about macros that make them superior to write domain-specific languages over ordinary functions?
John the Statistician
JtS: You'd need a lot of quoting (admittedly a related feature) to delay the evaluation of everything, for one. Macros let you avoid that, by letting you do arbitrary things at compile-time.
Ken
That's fair enough. It's one more step to avoid reading complexity while writing the code while being efficient at running it.
John the Statistician
+3  A: 

With macros you can define your own syntax, thus you extend Lisp and make it
suited for the programs you write.

Check out the, very good, online book Practical Common Lisp, for practical examples.

7. Macros: Standard Control Constructs
8. Macros: Defining Your Own

Nick D
+4  A: 

Pick any "code generation tool". Read their examples. That's what it can do.

Except you don't need to use a different programming language, put any macro-expansion code where the macro is used, run a separate command to build, or have extra text files sitting on your hard disk that are only of value to your compiler.

For example, I believe reading the Cog example should be enough to make any Lisp programmer cry.

Ken
+14  A: 

Source code transformations. All kinds.

  • you need a WHILE statement? Your language doesn't have one? Why wait for the benevolent dictator to maybe add one next year. Write it yourself. In five minutes.

  • You need twenty class declarations that almost look identical - only a limited amount of places are different. Write a macro form that takes the differences as parameter and generates the source code for you. Want to change it later? Change the macro in one place.

  • You want add code into the source tree? A variable really should be a function call? Wrap a macro around the code that 'walks' the source and changes the places where it finds the variable.

  • you want to write your code in postfix form? Use a macro that rewrites the code to the normal form (prefix in Lisp).

  • You need to run some code in the compiler environment to inform the development environment about definitions? Macros can generate code that runs at compile time.

  • You want to simplify some code at compile time? Use a macro that does the simplification - that way you can shift work from runtime to compile time, based on the source forms.

  • You need to write a complex mix of classes. For example your window has a class, subpanes have classes, there are space constraints between panes, you have a command loop, a menu and a whole bunch of other things. Write a macro that captures the description of your window and its components and creates the classes and the commands that drive the application - from the description.

  • some language syntax looks not very convenient? Write a macro that makes it more convenient for you, the application writer.

  • You need a language that is nearer to the domain of your application? Create the necessary language forms with a bunch of macros.

The basic idea: everything that is on the linguistic level (new forms, new syntax, form transformations, simplification, IDE support, ...) can now be programmed by the developer piece by piece - no separate macro processing stage.

Rainer Joswig
+1  A: 

Besides extending the language's syntax to allow you to express yourself more clearly, it also gives you control over evaluation. Try writing your own if in your language of choice so that you can actually write my_if something my_then print "success" my_else print "failure" and not have both print statements get evaluated. In any strict language without a sufficiently powerful macro system, this is impossible. No Common Lisp programmers would find the task too challenging, though. Ditto for for-loops, foreach loops, etc. You can't express these things in C because they require special evaluation semantics (people actually tried to introduce foreach into Objective-C, but it didn't work well), but they are almost trivial in Common Lisp because of its macros.

Chuck
A: 

R, the standard statistics programming language, has macros (R manual, chapter 6 - see www.r-project.org). You can use this to implement the function lm(), which analyzes data based on a model that you specify as code.

Here's how it works: lm(Y ~ aX + b, data) will try to find a and b parameters that best fit your data. The cool part is, you can substitute any linear equation for aX + b and it will still work. It's a brilliant feature to make statistics computation easier, and it only works so elegantly because lm() can analyze the equation it's given, which is exactly what Lisp macros do.

Noah Lavine
+2  A: 

Anything youi'd normally want to have done in a pre-processor?

One macro I wrote is for defining state machines for driving game objects. It's easier to read the code (using the macro) than it is to read the generated code:

(def-ai ray-ai
  (ground
   (let* ((o (object))
          (r (range o)))
     (loop for p in *players*
           if (line-of-sight-p o p r)
           do (progn
                (setf (target o) p)
                (transit seek)))))
  (seek
   (let* ((o (object))
          (target (target o))
          (r (range o))
          (losp (line-of-sight-p o target r)))
     (when losp
       (let ((dir (find-direction o target)))
         (setf (movement o) (object-speed o dir))))
     (unless losp
       (transit ground)))))

Than it is to read:

(progn
 (defclass ray-ai (ai) nil (:default-initargs :current 'ground))
 (defmethod gen-act ((ai ray-ai) (state (eql 'ground)))
            (macrolet ((transit (state)
                         (list 'setf (list 'current 'ai) (list 'quote state))))
              (flet ((object ()
                       (object ai)))
                (let* ((o (object)) (r (range o)))
                  (loop for p in *players*
                        if (line-of-sight-p o p r)
                        do (progn (setf (target o) p) (transit seek)))))))
  (defmethod gen-act ((ai ray-ai) (state (eql 'seek)))
            (macrolet ((transit (state)
                         (list 'setf (list 'current 'ai) (list 'quote state))))
              (flet ((object ()
                       (object ai)))
                (let* ((o (object))
                       (target (target o))
                       (r (range o))
                       (losp (line-of-sight-p o target r)))
                  (when losp
                    (let ((dir (find-direction o target)))
                      (setf (movement o) (object-speed o dir))))
                  (unless losp (transit ground)))))))

By encapuslating the whole state-machine generation in a macro, I can also ensure that I only refer to defined states and warn if that is not the case.

Vatine
though the latter is not good code anyway and hiding it behind a macro does not make it really better. It just 'looks' better. But that's the danger - instead of writing better code, one now writes macros to 'improve' the code on the surface. Generally the approach to have more descriptive code is right, but the code below needs to be well thought out.
Rainer Joswig
Coupld you be a bit more specific as to why it's "not good code"? I'm more than happy to have criticism of my code, but something a bit more constructive than "that's not good" would be appreciated. I'm pretty sure you have my email address if the comment box is too small.
Vatine