Explanation of macros; Haskell macros

[Stephen J. Bevan]

Kenny Tilton <ktilton at nyc.rr.com> writes:
> > 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.

As I noted in the section you snipped, an AWK-like solution looks
pretty poor to someone used to using Lisp style macros.  However, lots
of people take the AWK-like approach because it works for them with
whatever language they are currently using.  Simply telling them it is
a poor way to work is not going to win them over to macros.  Showing
them examples of how macros simplfy a given problem in Common Lisp are
useful but can still fall flat if they can't identify with that
problem.  What they want to see is either a Common Lisp (with macros)
solution to their problem or an example of a known problem with a
solution recast in Common Lisp utilising macros.  That obviously
pushes a lot of effort on those who want to make the case for macros.


> 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.

I don't think it is like saying that at all, but rather than digress
let's just try and avoid similies or analogies altogether.


> 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!

Telling people that they are producing "Turing-equivalent
non-responses" isn't going to win them over either.