Re: Teaching new tricks to an old dog (C++ -->Ada)

["Paul Mensonides" <leavings@comcast.net>]

jayessay wrote:
> Hyman Rosen <hyrosen@mail.com> 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