How Lisp macros differ from static code-generation and metaprogramming • Hacker News Board

Re: How Lisp macros differ from static code-generation and metaprogramming

#81

Post by nkurz » Sat, Jan 29, 2011, 10:32 PM UTC

dexen wrote: post #70

nkurz wrote: post #68

> Except, of course, that doesn’t work. The preprocessor > only makes one pass through the file, meaning a macro > can’t call another macro. macro.c: #include #define LOOP(n) for (int i = 0; i Of course macros can call other macros: http://gcc.gnu.org/onlinedocs/cppinternals/Macro-Expansion.h... Ignoring his poorly protected macros, and taking nothing away from Lisp, am I missing some subtle point he's making, or is…

A C macro can't directly -- nor indirectly -- refer to itself; even through other macro. You can't do loops, you can't do recursion. (a nonsensical example, as I can't think of a proper one right now) #define PRINTFOO PRINTBAR #define PRINTBAR PRINTFOO PRINTFOO The ANSI C standard says a macro, while it is being expanded by the preprocessor, ``is painted blue'' (is no subject to further expansion). I'm not sure, but…

Do you have a link for the "painted blue" reference? I agree with your explanation, but had never heard that particular phrasing and was intrigued by it. But searching on Google for things like 'expand ansi macro "painted blue"' returns only your comment and a scraped spam site of someone answering a similar question.

Re: How Lisp macros differ from static code-generation and metaprogramming

#82

Post by draegtun » Sun, Jan 30, 2011, 1:02 PM UTC

Xurinos wrote: post #31

funptr wrote: post #22

Earlier quoted context omitted.

C99 + GCC extensions + POSIX: #define for_duration(seconds, body) \ { \ pthread_t tid_task, tid_watcher; \ \ void* task(void* arg) { \ body ; \ pthread_cancel(tid_watcher); \ return NULL; \ } \ \ void* watcher(void* arg) { \ sleep((seconds)); \ pthread_cancel(tid_task); \ return NULL; \ } \ \ pthread_create(&tid_task, NULL, &task, NULL); \ pthread_create(&tid_watcher, NULL, &watcher, NULL); \ pthread_join(tid_task, N…

Is there a C macro that can do this? (defmacro execute-in-reverse (&body body) `(progn ,@(reverse body))) (execute-in-reverse (print "Hi") (print "Middle") (print "Bye")) Prints... "Bye" "Middle" "Hi" Point: You can do whatever you want with the symbols sent to the macro, whatever their contents. Mahmud's wrapper macro is trivial (it could be done with lambdas). Lisp's macro system allows you to create new syntax, in…

Wonderful example of what macros can do.

Just for shit & giggles I'd thought I give it a go in Io (http://www.iolanguage.com):

    executeInReverse := method (
        m     := call argAt(0)
        stmts := list()              // list of statements (ie. messages)
    
        loop (
            rest := m next           // rest of messages after current 
            stmts append(m setNext)  // get current message
            m := rest
            if (m == nil, break)     // exhausted statements when "nil"
        )

        stmts reverseForeach (n, doMessage(n))
    )

    executeInReverse( writeln("Hi") writeln("Middle") writeln("Bye") )

And I think with a bit more work I can get it to amend its AST rather than rerunning the loop each time it sees executeInReverse.

Re: How Lisp macros differ from static code-generation and metaprogramming

#83

Post by dexen » Mon, Jan 31, 2011, 7:49 AM UTC

nkurz wrote: post #81

dexen wrote: post #70

Earlier quoted context omitted.

A C macro can't directly -- nor indirectly -- refer to itself; even through other macro. You can't do loops, you can't do recursion. (a nonsensical example, as I can't think of a proper one right now) #define PRINTFOO PRINTBAR #define PRINTBAR PRINTFOO PRINTFOO The ANSI C standard says a macro, while it is being expanded by the preprocessor, ``is painted blue'' (is no subject to further expansion). I'm not sure, but…

Do you have a link for the "painted blue" reference? I agree with your explanation, but had never heard that particular phrasing and was intrigued by it. But searching on Google for things like 'expand ansi macro "painted blue"' returns only your comment and a scraped spam site of someone answering a similar question.

Indeed surprisingly hard to find a first hand reference. But http://duckduckgo.com/?q=%22painted+blue%22+expansion returned link to wikipedia article, which, in turn, links to some meta-document about new C standard. There's also some post on Boost (library) mailing list: http://duckduckgo.com/?q=macro+%22painted+blue%22+boost -> http://lists.boost.org/Archives/boost/2006/01/99264.php

Perhaps I was wrong; perhaps the phrase was in K&R C? Can't find the book online @_@;;

Re: How Lisp macros differ from static code-generation and metaprogramming

#84

Post by eru » Thu, Feb 03, 2011, 11:12 PM UTC

tygorius wrote: post #79

eru wrote: post #75

Earlier quoted context omitted.

Lisp and Forth are both very simple systems in terms of basic concepts, and push them to their limits. Both are quite flexible. Forth often runs on the bare metal, and exposes everything below. Lispers are customarily more shielded. Both encourage code to be treated as data and vice versa (without even looking at macros), but Lisp builds on the lambda calculus to do that, while Forth just sees code and data as being…

Sorry for the belated response, but for a sense of closure, so to speak, I'll add that I agree with your general assessment. Both languages started with a simple core that allowed developers to take some basic ideas and see just how far they could go with them. It just didn't occur to me to describe that as "opposite". Interestingly, both languages wound up with a schism of framework enthusiasts (CLOS & "big Forths")…

I wish HN would give me the option of bubbling up old threads that got new comments.

And you are right about my example with the deep stack. I probably did not remember correctly. The variable array was probably something with passing around an address plus length on the stack---while Lispers prefer that as one object.