Scripting C++ -- Boost.Python vs CORBA vs ???

[David Abrahams]

"Ira D. Baxter" <idbaxter at semdesigns.com> wrote in message
news:3c7befb8$1 at giga.realtime.net...
> > What's in it for the compiler writer people?

> Full employment? More importantly for EDG anyway, a broader market base.

That only counts if someone is willing to pay them for the technology to
make documentation or wrapping tools. My customers all insist on open source
in these areas, so I don't think it's going to make EDG excited... but who
knows, maybe I'll ask them.

> Now, if what you want to do is compiler-like, then throwing
> away the comments, line numbering, number formats,
> and preprocessor instructions is just fine.  And you
> generally only have to focus on one "file" at time.

You can't throw away line numbering if anyone is going to debug the
generated code. If you have the line numbering and the source code, you can
get the comments and the preprocessor instructions. Number formats? I
presume you mean 0xF vs. 15 vs. 1.5E1? I can see how that could be relevant
to a few jobs, but none I want to do in the near term.

> If, however, you want to modify the sources of the program,
> *retaining* all that information, then you can't use
> a conventional compiler technology front end.
> You need to have something that can parse the sources,
> *including* the preprocessor directives.
> One of DMS's unique properties is its ability
> to do that (with some constraints) for C and C++
> code.

What are the constraints? If, like most tools out there which are not
compilers, it doesn't handle the full C++ language (less export), I'm not
interested.

> A second unique property is the ability to parse
> entire suites of files in the same session, so
> that you can build analysis tools that operate
> across file boundaries (i.e., multiple compilation units)
> and make modifications that move code/data
> from one source file to another to accomplish
> refactoring activities.

It sounds neat. The PDT appears to do this by merging multiple parse runs. I
suppose that your approach could be more-efficient, but AFAIK the C++
compilation model is not very friendly to re-use of information across
translation units, due to visibility and ordering dependencies.

> A third unique property of such generalized front ends
> is the ability to *mix* notations from multiple programming
> languages in patterns to enable translation from one langague/dialect
> to another.
>
> Of course, our hope is to be fully employed building/selling
> reengineering tools rather than compilers.

Been watching your company on-and-off for a few years now. It sounds like
fascinating work, but you don't present your message in a way that's
compelling and understandable to me (and I'm a languages guy). I'd be really
interested to see the "killer application" of your technology in action.

-Dave