Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Lisp macros differ from static code-generation and metaprogramming

brandonbyars.com

Post reply on HN
Print view View original

71–80 of 84 posts

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

#71

Post by cyrus_ »

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…

correct, not Turing-complete

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

#72

Post by draegtun »

gnosis wrote: post #19
draegtun wrote: post #13

Earlier quoted context omitted.

1. Macros aren't unique to lisp. Perl6 also has macros ( http://en.wikipedia.org/wiki/Perl_6#Macros ) though they haven't been implemented in Rakudo yet. Also Ioke states that it has macros. 2. Metaprogramming's power ... The best example I know of is Io where pretty much anything other than commas and parentheses... Touched on Io introspection/metaprogramming before on HN: * http://news.ycombinator.com/item?id=18045…

The question isn't so much whether other languages have something they call "macros", but whether their macro systems approach Lisp's in power, flexibility, ease of use, integration with the language, and natural fit on to the language representation? Or is the macro system in question more of a Turing tarpit?

I believe Perl6 will fulfil those requirements because the language is built & hosted upon Perl6 Grammars which makes it totally reconfigurable.

ref:

* http://en.wikipedia.org/wiki/Perl_6_rules

* http://news.ycombinator.com/item?id=1280021

* http://perlcabal.org/syn/S06.html#Macros

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

#73

Post by Someone »

tygorius wrote: post #66
eru wrote: post #51

Earlier quoted context omitted.

Forth is almost the complete opposite of Lisp, and thus very similar.

You're gotten a number of up-votes, yet this statement makes as much sense to me as saying bananas are the complete opposite of apples. You can make a case of similarity or dissimilarity depending on which language aspect you focus on. But, "opposite"? I have no idea what that means.

Let me guess at some of what (s)he means:

Forth is an interpreter that can be switched into compilation mode, Lisp is a compiler that can be switched into interpreter mode. [edit: thinking of that, this more reflects how I have used the two than what they are. Lisps start in an eval loop, too, yet they feel different to me]

Forth is postfix, Lisp is prefix.

Forth programmers know their stacks are the environment, but rarely think of it as an environment. Lisp programmers know their environment is in some stack-like data structures, but rarely think of those stacks.

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

#74

Post by Locke1689 »

cyrus_ wrote: post #71
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…

correct, not Turing-complete

Note that this was, in fact, by design. Anyone who seeks to make C more complicated than this should be shot on sight.

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

#75

Post by eru »

Someone wrote: post #73
tygorius wrote: post #66

Earlier quoted context omitted.

You're gotten a number of up-votes, yet this statement makes as much sense to me as saying bananas are the complete opposite of apples. You can make a case of similarity or dissimilarity depending on which language aspect you focus on. But, "opposite"? I have no idea what that means.

Let me guess at some of what (s)he means: Forth is an interpreter that can be switched into compilation mode, Lisp is a compiler that can be switched into interpreter mode. [edit: thinking of that, this more reflects how I have used the two than what they are. Lisps start in an eval loop, too, yet they feel different to me] Forth is postfix, Lisp is prefix. Forth programmers know their stacks are the environment, but…

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 contents of memory.

In Forth if there's a bunch of data flowing into a word, you might put the number of arguments on the top of the stack and the other arguments below. Lispers would run away screaming from this manual and error-prone approach.

Lispers like to build e.g. their their own object system, if necessary. And in Forth it's easy to tag on a garbage collector---from within the language.

I hope that's some meat to back up my assertion. I hope I got some good examples. What I really want to say, is that the languages feel related in spirit. But less like brothers, more like to generals from opposing armies still respecting each other.

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

#76

Post by JeanPierre »

ekiru wrote: post #55
JeanPierre wrote: post #45

Seeing how this guy comments about loop, be a little careful when using it. There is no formal standard on how to implement loop, so what you write might result in different answers depending on what Common Lisp implementation you use. Evaluate these loop-expressions and see what happens (from ANSI Common Lisp by PG): (loop for y = 0 then z for x from 1 to 5 sum 1 into z finally (return (values y z))) and then evalua…

What aspects of the actual behavior of loop are unspecified?

How to combine them is poorly defined and complex. The loop clauses by themselves is not the problem.

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

#78

Post by jongraehl »

Metaprogramming is a more general concept than the author claims. For example, lisp macros and eval/quote (at any level of compilation or runtime) are particular metaprogramming facilities. You can even metaprogram using only explicit code quotation if you prefer (with no implicit reflection exposure of regular code).

I agree with the definition at http://en.wikipedia.org/wiki/Metaprogramming

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

#79

Post by tygorius »

eru wrote: post #75
Someone wrote: post #73

Earlier quoted context omitted.

Let me guess at some of what (s)he means: Forth is an interpreter that can be switched into compilation mode, Lisp is a compiler that can be switched into interpreter mode. [edit: thinking of that, this more reflects how I have used the two than what they are. Lisps start in an eval loop, too, yet they feel different to me] Forth is postfix, Lisp is prefix. Forth programmers know their stacks are the environment, but…

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") vs. minimalists (Scheme & Moore loyalists (for want of a better term)).

As an aside, your bunch of data example would run afoul of Forth catechism. The normal response would be to use a dictionary address or even address and offset to access a data structure. Antagonism to deep use of the data stack is so prevalent that Moore eventually reached the point with his chip designs of implementing the top of stack as a couple of on-chip registers -- if what you want isn't within the top couple of stack entries, so the logic goes, then you've failed to factor your design properly. Perhaps this preoccupation with very low level operations is an aspect where Forth programming might be considered the opposite of normal Lisp programming.

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

#80

Post by sedachv »

sedachv wrote: post #37
igravious wrote: post #8

Are natural languages homoiconic? (If you get my drift.) Does that question even make sense?

Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo But seriously, take a look at Quines and Hofstadter's Godel, Escher, Bach

I was re-reading Doug Hoyte's Let Over Lambda today, and came across this quine:

  (let ((let '`(let ((let ',let))
                 ,let)))
    `(let ((let ',let))
       ,let))
Originally from: http://www.scribd.com/doc/47702904/Bawden-Quasi-Quotation-in...
Post reply on HN