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,FREEMAIL_FROM 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!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 29 Mar 2005 04:17:39 -0600 From: "Paul Mensonides" Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng 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> Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: Tue, 29 Mar 2005 02:17:37 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-ID: NNTP-Posting-Host: 24.17.165.235 X-Trace: sv3-DdOd1dT8p1AczwiyYxQuCU1ZCf+74/PP2jTPIAQHo07qW3llF9jYOz7XlxtJl4xGGfPOT7PPcZYqJpB!gwHvF+swGS6/rBymapbgcddDkp76Pz+yea7/RMG0Fw60rXccCPldCBxdl+Buyg== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.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.31 Xref: g2news1.google.com comp.lang.ada:10113 comp.lang.c++:47758 comp.realtime:1810 comp.software-eng:5452 Date: 2005-03-29T02:17:37-08:00 List-Id: jayessay wrote: > Hyman Rosen writes: > >> Jerry Coffin wrote: >>> I see. So what is it that (you incorrectly believe) the C >>> preprocessor can do that a Lisp macro can't do? >> >> Can Lisp macros manipulate the text of the macro arguments? > > They don't manipulate text at all, but they _do_ manipulate the > _un_evaluated forms passed to them. > > Here is a "top 5" list of why Lisp macros aren't anything like C > preprocessor stuff. At the bottom I give an example. Nobody said that the mechanisms are equivalent. Lisp macros are like C/C++ macros in a pretty major way: they parametize code with code. > Number 5: > > The/a cpp is a, well, preprocessor. Typically a separate program > even. While you could dilute the meaning here to the point where a > compiler is a preprocessor for a linker is a processor for a loader is > a preprocessor for a cpu etc., the typical meaning is that such things > perform minor transformations on a block of input and had the result > to the primary processor. > > 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. > Number 4: > > The/a cpp is not Turing complete. Yes it is. > Number 3: > > 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. > 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. > Number 2: > > 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. > 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? 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. > ----------------------------- > > 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. The template mechanism parametizes code with types (primarily) and only indirectly parametizes code with code. 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--regardless of when or where that can happen. That is the same capability that C/C++ macros have. Does Lisp do it better? Yes. Does Scheme do it better still? Yes. Neither of those answers precludes the similarity in what the mechanisms do, nor do any of your reasons. Regards, Paul Mensonides