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

["Jerry Coffin" <jcoffin@taeus.com>]

Martin Dowie wrote:
> Jerry Coffin wrote:
> > Just for one obvious example, Ada doesn't provide an easy way to
> > express/do most of the things one can do with the C or C++
> > preprocessor. It provides some alternative in _some_ cases, but
> > quite frankly, these are really the exceptions rather than the
> > rule.
>
> That 'problem' isn't unique to Ada - I can't think of another
> language that *does* define a pre-processor.

A preprocessor per so, no. The type of capabilities is a different
story. For example, Lisp includes macros. Most assemblers include (much
more extensive) macros as well as an eqiuvalent of C's
#if/#ifdef/#ifndef/#endif. Literal defininitons in PL/M provided some
of the same capabilities as C macros. I could go on for a while, but
you get the general idea -- the general capabilities aren't entirely
unique to C and C++, but are almost entirely missing from Ada.

> And if you like a preprocessor - just use one! You can always write
> a makefile/.bat/.com/<whatever> to invoke the preprocessor before the
> compiler is called. GNAT comes with an Ada-centric preprocessor but
> there is nothing to stop you using the 'C' one.

This merely changes the problem rather than solving it. Many typical
uses of the preprocessor in C are to deal with portability issues, but
you're asking that they be dealt with by adding yet another program to
be ported.

Even ignoring that, the system is essentially unusable. C and C++
compilers (admittedly, more or less out of necessity) provide
directives so the preprocessor can specify which line in the original
source code resulted in a particular line that was given to the
compiler. This allows the compiler to refer error messages back to the
correct line in the original source code quite easily, and the
compilers do so quite dependably. TTBOMK, Ada compilers don't
(normally) support such directives, rendering the system impractical at
best because error messages are essentially always incorrect.

[ ... ]

> See Ada.Exceptions - perhaps not as elegant but it does the job and
> back when the first exception mechanism for Ada was designed, I doubt
> there was much call for anything other than a 'this fault has
> occured' style exception. At the time, I'd guess that 90%+ of all
> code in exsistance was COBOL, C or FORTRAN - none of which had any
> exception handling!

Having no exceptions at all means you report errors in some other
fashion, and you're free to design one that's as expressive as you
need. The exception handling in Ada is inadequate to the job (at least
IME), but its presence makes it virtually impossible to convince
anybody to accept anything else either.

In many cases, having a feature in an inadequate form is really _worse_
than not having it at all, even if the basic idea of the feature is a
good one. Having the feature rules out alternatives (in may people's
minds), even when they're really superior.

>  > Only exact matches
>  > are supported and no information is included beyond the identity
>  > of the exception.
>
> True for Ada83 but not so in Ada95 - again see Ada.Exceptions and
> getting expanded again in Ada2005.

This clearly allows more information to be transmitted, which I'd
consider an improvement. Perhaps I'm missing something, but I still
don't see a provision for anything equivalent to catching a reference
to a base class in C++, at least as of Ada 95. Is this being added in
Ada 2005, or have I mis-read things?

> >  And, once
> > again, the addition of tagged records to Ada 95 testifies to the
> > fact that even its own designers recognized the improvement this
> > adds in general, but (whether due to shortsightedness, concerns
> > for backward compatibility or whatever) didn't allow this
> > improvement to be applied in this situation.
>
> Almost certainly backwards compatibility - but I'm sure Bob and/or
> Randy could shed more light on that...

That certainly seems like the obvious guess. In the end, it may explain
the situation, but doesn't really improve it. The same, of course,
applies to C++, which clearly makes some sacrifices to maintain a high
degree of compatibility with C. At the same time, I have to say that
IMO, C++ gains more (e.g. C has a much larger user base) while
sacrificing less (C compatibility has produced minor annoyances into
C++, but IMO Ada's exception handling is sufficiently broken that it
seriously detracts from the language).

-- 
    Later,
    Jerry.