Re: [MMXX-dev] Generator utility

[Frank V. C. <fr...@co...>]

Luca Raggi wrote:
> 
> 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.

Not required. As I said, it would have to emit MMXX laden headers and
module stubs. It is a convenience for the learned, and an entry for the
beginner. It is up to each user if they want to "hand-craft" their MMXX
classes, and there would be nothing to stop them.

> 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.

I agree, but by the same token the user is not prevented from adding
arbitrary (and incorrect) type references anywhere. The compiler would
error/warn them at that point.
 
> 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.
> 

In my most recent involvement in meta class implementation, we used NIH
Class Class with a bunch of macros, in large part reduced to the
implementation requirement of:

DECLARE_CLASS_NIH( SomeName );

class SomeName
{
	DECLARE_METHODS_NIH( SomeName );
public:
	// ...
};

and in the module

DEFINE_CLASS_NIH( SomeName );


which equiped us with Factories, RTTI (not C++ RTTI), SmartPointers,
etc.

> 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.

Obviously we are strong believers in Meta-data driven function!
 
> 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.

I believe ANTLR has a C++ grammar already defined, which would make this
much easier, like adding keywords which allowed pass-through statements
for MMXX implemented classes, versus discoverable shadow/proxy methods.

 
> 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.

I would stay away from this for now (resources).
 
> 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...

One can dream, for now it is a convenience to anyone wanting to get
going with MMXX without a lot of learning. Believe it or not I have
found that there is a large number of developers that are unfamiliar
with meta indirection, and resistence to learning it. Mainly because "I
have enough on my plate. Am I coding C++, fine, don't add alot of new
terms and methodology."

You overcome that by KISS.

-- 
Frank V. Castellucci