Home » Community » Forums » » Concerning Lisp
  Intel sponsors gamedev.net search:   
[Control Panel] [Register] [Bookmarks] [Who's Online] [Active Topics] [Stats] [FAQ] [Search]

Add Forum to Favorites |  Send Topic To a Friend | View Forum FAQ | Track this topic


 Last Thread Next Thread 
 Concerning Lisp
Post Reply 
While the article is a good intro to the power of Lisp, 'unless' is a poor example of the power of Lisp's macros. You could do the exact same kind of thing in C with a simple #define unless(x) if(!(x)). It really surprise me how many people don't realize you can do such things in C (I've seen at least 3 people ask for a better macro system for C giving that as an example as something they want to be able to do)

 User Rating: 1866   |  Rate This User  Send Private MessageView ProfileView JournalView GD Showcase Entries Report this Post to a Moderator | Link

The big difference between macros in C, and macros in Lisp (one that was not touched upon in the artice) is that in Lisp, there is absolutely no difference between a function and a macro except for the fact that functions are executed at runtime and macros are executed at compile time.

What this means is that a Lisp macro can perform IO, computations, call other functions, call other macros, receive variables etc. Everything that a function can do, except that this is done at compile time.

An example of a Lisp macro that I find useful: In OpenGL, glPushMatrix() and glPopMatrix() are called all the time.

A simple Lisp macro extends the language:

(defmacro with-glPushMatrix (&body body)
    `(progn
        (glPushMatrix)
        (unwind-protect
            (progn ,@body)
            (glPopMatrix))))
    


to allow this...

(defun draw-objects ()
    (with-glPushMatrix
        (glRotatef *view_rotx* 0.0 1.0 0.0)
        (glRotatef *view_roty* 1.0 0.0 0.0)    
        (glRotatef *view_rotz* 0.0 0.0 1.0)
        
        (with-glPushMatrix
            (glTranslatef (- 3.0) (- 2.0) 0.0)
            (glRotatef *angle* 0.0 0.0 1.0)
            (glCallList *gear1*))
        
        (with-glPushMatrix
            (glTranslatef 3.1 (- 2.0) 0.0)
            (glRotatef *angle* 0.0 0.0 1.0)
            (glCallList *gear2*))
        
        (with-glPushMatrix
            (glTranslatef (- 3.1) 4.2 0.0)
            (glRotatef *angle* 0.0 0.0 1.0)
            (glCallList *gear3*))))
   


All code within with-glPushMatrix is automatically wrapped between glPushMatrix() and glPopMatrix() calls. These calls can even be nested with glPopMatrix() being called correctly on the way out, eliminating the bug of not matching a push with a pop.

Also, everything is automatically indented allowing for easy reading of the code.

This shows one of Lisps greatest strengths: In other languages, e.g. C/C++, the problem is broken down into smaller and smaller pieces until it can be implemented in code. In Lisp, the language is extended and brought UP to the problem domain. The language is made to fit the problem.

-Luke


[edited by - HairyTroll on June 24, 2003 7:06:09 PM]

[edited by - HairyTroll on June 24, 2003 7:11:35 PM]

 User Rating: 1061   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

So is this why LISP is a "scripting language"?

 User Rating: 1015    Report this Post to a Moderator | Link

Wow, thats some serious necromancy you have. On the 3rd aniversary of it's dying post too.

 User Rating: 1589   |  Rate This User  Send Private MessageView ProfileView Journal Report this Post to a Moderator | Link

While this thread is active...

Quote:
Original post by HairyTroll
The big difference between macros in C, and macros in Lisp (one that was not touched upon in the artice) is that in Lisp, there is absolutely no difference between a function and a macro except for the fact that functions are executed at runtime and macros are executed at compile time.

What this means is that a Lisp macro can perform IO, computations, call other functions, call other macros, receive variables etc. Everything that a function can do, except that this is done at compile time.

An example of a Lisp macro that I find useful: In OpenGL, glPushMatrix() and glPopMatrix() are called all the time.

A simple Lisp macro extends the language:

(defmacro with-glPushMatrix (&body body)
    `(progn
        (glPushMatrix)
        (unwind-protect
            (progn ,@body)
            (glPopMatrix))))
    


to allow this...

(defun draw-objects ()
    (with-glPushMatrix
        (glRotatef *view_rotx* 0.0 1.0 0.0)
        (glRotatef *view_roty* 1.0 0.0 0.0)    
        (glRotatef *view_rotz* 0.0 0.0 1.0)
        
        (with-glPushMatrix
            (glTranslatef (- 3.0) (- 2.0) 0.0)
            (glRotatef *angle* 0.0 0.0 1.0)
            (glCallList *gear1*))
        
        (with-glPushMatrix
            (glTranslatef 3.1 (- 2.0) 0.0)
            (glRotatef *angle* 0.0 0.0 1.0)
            (glCallList *gear2*))
        
        (with-glPushMatrix
            (glTranslatef (- 3.1) 4.2 0.0)
            (glRotatef *angle* 0.0 0.0 1.0)
            (glCallList *gear3*))))
   


All code within with-glPushMatrix is automatically wrapped between glPushMatrix() and glPopMatrix() calls. These calls can even be nested with glPopMatrix() being called correctly on the way out, eliminating the bug of not matching a push with a pop.

Also, everything is automatically indented allowing for easy reading of the code.

This shows one of Lisps greatest strengths: In other languages, e.g. C/C++, the problem is broken down into smaller and smaller pieces until it can be implemented in code. In Lisp, the language is extended and brought UP to the problem domain. The language is made to fit the problem.

-Luke

Actually, that's probably not the best example, either. The only reason you even need a macro in the first place is because opengl uses a stack-based interface.

 User Rating: 984   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

All times are ET (US)

Post Reply
 Last Thread Next Thread 
Forum Rules:
You may not post new threads
You may post replies
You may not edit your posts
You may not use HTML in your posts
Jump To:
Administrative Options: