From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.rcn.net!news.rcn.net.POSTED!not-for-mail NNTP-Posting-Date: Tue, 29 Mar 2005 10:31:39 -0600 Sender: jsa@rigel.goldenthreadtech.com Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <1111607633.301232.62490@z14g2000cwz.googlegroups.com> <1111628011.160315.134740@o13g2000cwo.googlegroups.com> <1111794348.874993.298340@g14g2000cwa.googlegroups.com> <1111827755.497376.232760@z14g2000cwz.googlegroups.com> From: jayessay Organization: Tangible Date: 29 Mar 2005 11:37:01 -0500 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 209.6.25.79 X-Trace: sv3-hODR6bj40n+E3PePrFaQvhGXsntOqaI+pBJOHGc1A8/qc5KbtWShis57SK5s66rd+QGBe7zLrfXsc6k!W/zqvBLmi8AYrrKdN2wgcp2YLnEAzvTkmQbgfpqxbXawxvGe8AkWgMDaIf9XZOFXnMDuVpN8JcAD X-Complaints-To: abuse@rcn.net X-DMCA-Complaints-To: abuse@rcn.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:10124 comp.lang.c++:47804 comp.realtime:1814 comp.software-eng:5456 Date: 2005-03-29T11:37:01-05:00 List-Id: "Paul Mensonides" writes: > Nobody said that the mechanisms are equivalent. Lisp macros are like C/C++ > macros in a pretty major way: they parametize code with code. No, they are fundamentally code _transformers_, not parametric substituters. > > Lisp macros are tightly bound up with both the definition of the total > > language and any implmentation of it. Also expansion time is > > interwoven with compilation, interpretation, or explicit evaluation. > > They are available and can be defined during any phase: compile, load, > > and execute/runtime. > > So what? Where and when they can be evaluated doesn't mean that the > mechanisms are totally dissimilar. OK, you would then also claim that the preprocessor is basically similar to the C++ compiler. Fine. I think that makes the term basically meaningless. > > The/a cpp is not Turing complete. > > Yes it is. No, it is not. The only way to get it to act as such is to run it in phases over its own output. > > The/a cpp processes text, typically from a text stream such as (most > > typically) a text file. > > No, a C or C++ preprocessor processes tokens, not text. No, the _input_ is _text_. Of course it turns that into _tokens_ but that is _irrelevant_ > > Lisp macros process _data structures_. In particular the syntax trees > > output from the parser. Text is long gone before macros are involved > > at all. > > So what? A syntax tree is code, as is source code text. You can't be serious. OK, so the source code of a C++ program is the same as the AST produced by the frontend. You have again rendered the term "syntax tree" basically meaningless. > > The/a cpp doesn't know or have any access to the full language, user > > defined functions, or its environment. > > So what? This is the same thing as your fifth reason. When or > where it can be evaluated doesn't change what it does. No it is not the same, and it is telling that you think it is. And it makes a huge difference. You can write programs with Lisp macros pretty much like you write any other program. You write them _in_ the language, not as some adjunct separate aspect to the language. That level of expressivity and use of previously defined libraries of functions is as important as being able to use class libraries and language intrincs in typical programs. I don't see how you can plausibly disagree with this. > > Lisp macros are just Lisp functions which can make use of the entire > > language, and any other user defined functions and macros in libraries > > or the running image. They also have access to their lexical > > environment information (such as type and profile information) as well > > as any public aspects of the global system/application. > > Again, so what? See above. To claim that this is a "so what" is to claim that there is no need or anything particularly useful about being able to use any language construct and/or library in programming any program. I suppose you don't realize that that is what you are actually saying here, because I can't believe you would actually think this. > There is no doubt that Lisp macros are superior to C/C++ macros in > most categories. However, that doesn't change what they > fundamentally do: parametize code with code. I'm afraid that saying its so doesn't make it so. They are code transformers. Of couse you can use them to "parameterize" code, but that is a single _use_ case. > > The astute reader will have noticed that it is C++ _templates_ which > > are slighly similar to Lisp macros. And they would be right. > > Templates are significantly less expressive and mind numbingly painful > > to use in comparison, but they are Turing complete and you can do some > > interesting things with them. > > C++ templates are similar to Lisp macros also, but C/C++ macros are > much closer. Not in their more fundamental character. Templates are about metaprogramming - not very potent example, but metaprogramming nonetheless. Lisp macros are still _the_ most capable extent example of metaprogramming. > The template mechanism parametizes code with types (primarily) and > only indirectly parametizes code with code. That's pretty irrelevant. > To reiterate: nobody has said that C/C++ macros are as powerful as > Lisp or Scheme macros. However, despite everything you say, Lisp > and Scheme macros parametize code with code And to reiterate, that is not what they primarily do. > better still? Yes. Neither of those answers precludes the > similarity in what the mechanisms do, nor do any of your reasons. That basically eliminates any meaning in most of the terms: "preprocessor", "compiler", "metaprogramming", "code transformer". Fine. But I think that's pretty extreme thing to do simply to try to pretend that C/C++ macros are anything like Lisp macros. /Jon -- 'j' - a n t h o n y at romeo/charley/november com