Interesting discussion!
I think about taking some of the topics into separate threads. Will
see, I'm a bit under project pressure. Wont tell you the language ;(
But, @Luc
"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."
Thats why I want to use a nifty metaphor ;-)
@all
After reading all your answers and discussion, I ponder whether the
words of
@ Laurent PETIT
"second major difference is that you stay in the same language
for writing macros or non macros code in Lisp"
are really true.
It is, of course, the same for my Java collegues, because its written
wit parentheses ;-)
But writing lambda forms - and this is what the usual functional
programming can be reduced to - and writing macros is very different.
Or is it not?
(At least to me it is.)
(Macros ar tree transformations. I have a hunch that maybe lambda can
be seen as a special form of such tree transformations (but I'm a
newbee here). If this is true, a new foundation of lisp may be
interesting. Not in lambda calculus, but in tree transformation
grammars. But that doesnt belong to this thread. Nevertheless,
comments are welcome :)
Thank you all, and kind regards, alux
On 9 Sep., 20:40, lprefonta...@softaddicts.ca wrote:
> 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
