Explanation of macros; Haskell macros

[Kenny Tilton]

Stephen J. Bevan wrote:
> "Coby Beck" <cbeck at mercury.bc.ca> writes:
> 
>>Here's a nice example from some production code I wrote that is easy to
>>grok.
> 
> 
...

> anything else.  For example, if the commands have any kind of grammar
> then solution is to define the grammar and let a parser generator take
> care of parsing and building an AST.  Whether the parser generator is
> an extension of the language (as is possible in Lisp and Forth) or a
> separate language (most other languages) is to a certain extent an
> implementation detail.

No, this misses the whole point. The idea precisely is not to have to 
jump out of the IDE, move to external tool X that has none of the 
knowledge available to code within the application, define a grammar 
which must now be kept in synch with new decisions made back in the HLL 
IDE (that is always /so/ much fun) to generate transformed code which 
must be regenerated in its entirety anytime the grammar changes.

That is like saying I do not need OO because I can have a type slot and 
all my code can dispatch off that, so there is my OO.

The world gets better when something you can do the hard way (and using 
AWK instead of macros really takes the cake on that score) gets 
supported by a polished language mechanism.

To a large degree, all these Turing-equivalent non-repsonses are doing a 
good job of explaining why macros are useful: who needs a jet to get 
from NYC to Beijing? C'mon, Amtrak, kayak, Great Wall...good morning, 
Beijing!

kenny

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application