The major thing that made me used macros as much as possible when available
in any language was writing assembly code. Not 100 lines projects, 20,000 and
above, mainly made of macro calls.
That's when you realize that you need to use macros to generate instructions
for three reasons:
a) keeping the code size of the system within reasonable limits
b) having the instant ability to change things "under the hood" by altering
your macros instead of erring in the code trying to find the spots where
you must add these new instructions you just find out you urgently need to
make it work.
c) to improve the code readability and maintainability by enforcing common
patterns in the code.
I was blessed to work on DEC environments where the macro processors were
very strong and much more sophisticated than the C preprocessor. Not as
good as Lisp but still very flexible and able to handle complex logic.
For some reason, many common languages of the 70s/80s were missing this
important feature, at least it was not in their respective standards (Cobol,
Fortran, Pascal, ...). I think only Pl1 had some.
One friend of mine in the 80s was working on a HP3000 in Cobol I think
and that implementation had a macro processor but that was an exception
at the time.
My first impression is that they are not enough main macro implementations
widely used these days aside from the C preprocessor which is pretty basic.
The macro feature by itself is probably an strange/alien concept for many
people today.
Learning Lisp by itself is a big chunk so pushing the advantage of Lisp
macros to the forefront is not obvious if the audience cannot compare
with another (good/simple) implementation they understand well.
Luc P.
Laurent PETIT <laurent.pe...@gmail.com> wrote ..
> 2010/9/9 Andrew Gwozdziewycz <apg...@gmail.com>:
> > On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT <laurent.pe...@gmail.com>
> > wrote:
> >> Hello,
> >>
> >> 2010/9/9 Sean Corfield <seancorfi...@gmail.com>:
> >>> On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava <patrickli_2...@hotmail.com>
> >>> wrote:
> >>>> I found the easiest way to introduce macros is just to introduce them
> >>>> as small syntactic sugaring. For example, getting rid of the explicit
> >>>> (fn [] ...) for macros like (with-open file ...).
> >>>
> >>> Interesting. I don't see any real difference between macros and C
> >>> preprocessor stuff and C++ templates at a conceptual level. I think
> >>> Clojure macros are much cleaner, but essentially they are similar. So
> >>> in the Java world, generics (templates) are not yet widely used
> >>> outside the libraries and maybe that's why Java devs find macros hard
> >>> to comprehend?
> >>
> >> I think that even at the conceptual level, the differences are big:
> >>
> >> a. C/C++ is a "pre-processor". It does a first pass on the code.
> >> Only at the end is the C/C++ compiler invoked. In Lisps, there is
> >> still this "first pass/second pass" thing, but it's at a waay finer
> >> granularity level: the top level form. At the end of the evaluation of
> >> each top level form, a new macro may have been defined and can be
> >> called immediately by the next top level form. So not only is the
> >> "set" of macros not closed in Lisp (and in C/C++, to some extent, it's
> >> also not closed, even if rather limited), but it can be expanded
> >> during the compilation of the "program".
> >
> > Of course the real difference is that in Lisp macros you are working
> > directly on the AST, where in C/C++ macros you're working at the
> > source level. My understanding of the C/C++ preprocessor is that it
> > more or less does a string substitution, which *may* lead to a syntax
> > errors (you often see #define X(y) do { y } while (0); to get around
> > different limitations), or undesired results, not to mention
> > unintended variable capture, etc, etc, etc.
> >
> > The fact that Lisp macros actually operate on the AST means that Lisp
> > macros can make *changes* to the AST (insert things, remove things,
> > rearrange things), and *not* just substitute FOO for BAR. This is a
> > hell of a lot more powerful.
>
> Yeah
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first
> post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
