alux <alu...@googlemail.com> wrote ..
> 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
Get them to write a few thousand lines of assembler, they will quickly
adopt macros believe me :))))
> 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
--
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
