Re: [MMXX-dev] Generator utility

[Luca R. <lj...@us...>]

On 5/2/2000 11:11 AM, Frank V. Castellucci (fr...@co...) 
shared his wisdom:

>Have you considered allowing the developer to use a declarative grammar
>which is then read and the resulting MMXX macro laden header is
>generated? This has already proven to be quite useful to CORBA
>developers (IDL grammer), as well as increasing the binding capability
>for other languages.

Yes, I've considered this. There are a number of interesting 
alternatives, so here's a few points:

1. It's a significant advantage if such an IDL is not strictly 
*required*, namely because it would require porting a parser to all 
development platforms and would not be instantly compatible with all IDEs 
and the like (on Mac for instance, the Metrowerks IDE has a Plugin API 
whereas MPW uses unix-like commmand line tools, on Windows you'd have 
MSVC which probably has its own plugin API, then there's Cygwin, and so 
on and so forth.) Some users will also see advantages in not having to 
double the number of files involved (.idl and generated .h) and in 
reducing makefile complexity.

2. Currently, MMXX headers can utilize type declarations in non-MMXX 
headers (e.g. fragile classes and templates, typedefs, STL declarations.) 
To maintain this property in an IDL parser, we'd either have to make it 
parse all C++ declarations (if we were to strong-check on types) or just 
have it swallow types it knows nothing about. The latter is obviously 
easier and more flexible, however successful parsing of a bad set of 
declarations might induce a false sense of security.

3. I've been able to implement pretty much all the required functionality 
by using the preprocessor and runtime code alone. I view this as an 
advantage in the design phase, in that it's kept me from adopting overly 
sophisticated and intrusive designs (yes it could have been worse! :-) 
that I would have probably opted for had I had all the freedom that comes 
with having a full-blown metacode generating parser. Consider CORBA's C++ 
binding for instance: CORBA's language independence at the IDL level 
forced a lot of foreign constructs into CORBA-enabled C++ applications, 
whereas as ugly as MMXX's .h grammar is, the .cpp files do not vary 
tremendously from what one would write without MMXX, with relatively few 
exceptions (i.e. x_ptr<>'s, VirtualDelete(), x_exception's and the likes.)

Most importantly, as you suggested we can still write an IDL parser and 
make it generate macro declarations, enhancing ease of use (particularly 
for first-time users) while maintaining all the advantages above. In 
other words, this thing screams to be disjoint. Also notice that if we 
wait to write one until after the header grammar is finalized, we don't 
have to revise the parser every time we make changes to the header 
grammar.

Once we get to it, here are some interesting alternatives:
a. Make it parse its own interface definition language.
b. Make it parse regular C++ declarations, but automatically make MMXX 
adjustments as needed where possible, and produce error messages whenever 
something is incompatible.
c. Make it parse CORBA's IDL.

Now a. is the relatively easy route to take, since it simplifies the 
parser considerably, and we can just syntax error anything that MMXX 
doesn't support.

Option b. comes with a really bitchy grammar, but it addresses the issue 
of external type imports (as in 2. above) and is also the easiest for new 
users to deal with.

Option c. is very nice in that it constitutes half the work needed to 
make a MMXX-based CORBA ORB. In the end, both the parser and the ORB 
would be optional add-ons, but it would be pretty cool in that any MMXX 
module could easily become a CORBA server. The biggest problem here is 
that CORBA comes with about a zillion constructs and specs of its own 
that would have to be reconciled at the parser level.

Now if I may digress a bit, option b. is also interesting in that it 
might lay the foundation for a plausible future integration of MMXX 
directly into a C++ compiler, a proposition which is automatically proven 
possible by the fact that a C++ compiler can already generate MMXX 
modules - it just has to be tricked into it. The MMXX facilities could be 
implemented as C++ extensions, and who knows, perhaps even provide some 
suggestions to the standards committee on how to address 
ABI/fragility/reflection issues in the next release of the standard...

Please continue sharing your thoughts as this is very much an open issue.

Ciao!
Luca