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

[jayessay <nospam@foo.com>]

"Paul Mensonides" <leavings@comcast.net> 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