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

61–70 of 84 posts

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

#61

Post by prodigal_erik »

kenjackson wrote: post #32
adobriyan wrote: post #24

Earlier quoted context omitted.

The reason Linux trace macros are insane is because C preprocessor is so primitive. Think about it. > they are quite powerful For small values of "quite". C macros are strictly less (and by large margin powerful than Lisp macros. One can't even use #ifdef inside #define!

Note, the power of the macro system is not equal to its general good. The C macro system was already too powerful, and one of the things that hurts languages is a preprocessor of virtually any kind. The badness of the C preprocessor starts much earlier with things like include files, and the fact that you can't statically analyze the code in any reasonable way. The benefit from the preprocessor is absurdly small. Wit…

It took five years for LINQ to be added to C# because it was too painful for anyone other than Microsoft to add any syntax to the language. Macros would have fixed that.

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

#62

Post by evanrmurphy »

In dialects that support fexprs such as Kernel, PicoLisp and Eight, you get something almost like first-class macros. Macros (or fexprs, rather) are then even more powerful, because they can be passed around as arguments to functions or even to other fexprs.

A key tradeoff is that they must be expanded at run-time, and in doing so they incur a performance penalty that doesn't exist with compile-time macros.

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

#63

Post by Dn_Ab »

prodigal_erik wrote: post #61
kenjackson wrote: post #32

Earlier quoted context omitted.

Note, the power of the macro system is not equal to its general good. The C macro system was already too powerful, and one of the things that hurts languages is a preprocessor of virtually any kind. The badness of the C preprocessor starts much earlier with things like include files, and the fact that you can't statically analyze the code in any reasonable way. The benefit from the preprocessor is absurdly small. Wit…

It took five years for LINQ to be added to C# because it was too painful for anyone other than Microsoft to add any syntax to the language. Macros would have fixed that.

it's interesting that you say this because Nemerle, another language on the .NET platform implemented LINQ into the language using Macros.

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

#64

Post by Dn_Ab »

grayrest wrote: post #6

A couple points on the metaprogramming space (these aren't about the article, but the article reminded me of them): 1. Macros aren't unique to lisp. They're most developed and used in the lisp family, but you don't need to have a homoiconic language to have macros. The Mirah programming language--statically typed Ruby on the JVM--has non-hygenic macros, I know there's been a number of efforts to add macros to coffees…

There is also template haskell. Nemerle is another non-homoiconic language with powerful metaprogramming abilities using hygienic macros. It really is quite impressive what those guys are doing. And it is such a contrast (not all inferior IMHO) to the lisp way. A dual approach maybe.

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

#65

Post by kenjackson »

prodigal_erik wrote: post #61
kenjackson wrote: post #32

Earlier quoted context omitted.

Note, the power of the macro system is not equal to its general good. The C macro system was already too powerful, and one of the things that hurts languages is a preprocessor of virtually any kind. The badness of the C preprocessor starts much earlier with things like include files, and the fact that you can't statically analyze the code in any reasonable way. The benefit from the preprocessor is absurdly small. Wit…

It took five years for LINQ to be added to C# because it was too painful for anyone other than Microsoft to add any syntax to the language. Macros would have fixed that.

Lambdas, type inference, extension methods, etc... all good stuff. LINQ itself they could have skipped. And if macros help accelerate more stuff like the syntax in LINQ -- well I think that proves my point.

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

#66

Post by tygorius »

eru wrote: post #51
tygorius wrote: post #48

So Lisp macros provide compile-time code generation, but in doing so, you have access not just to the code-generation instructions – which are just Lisp data – but also to the entire Lisp language and environment. The same can be said for classic Forth. Indeed, the enthusiastic way that Lispers describe macros I find eerily similar to how I used to hear Forthians describe their language. Except in Forth the relevant…

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.

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

#68

Post by nkurz » 

  > 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 the author just flat out wrong here? I think he's just wrong, and this makes it hard for me to even read the rest of his argument.

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

#69

Post by leppie »

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…

I noted this too. Seems the author has a broken C compiler.

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

#70

Post by dexen »

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 probably it follows the C macros are not Turing-complete.

EDIT: on the other hand, a LISP macro system is a Turing-complete programming language that's geared towards manipulating lists of symbols and values (which, incidentally, is LISP program).

Post reply on HN