Re: Ada generics

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

"Hyman Rosen" <hyman.rosen@gmail.com> writes:

> Markus E Leypold wrote:
>> I think the purpose is not "catching errors" but more likely delivering abstraction.
>
> True enough. Right now, that has to be handled in C++ by documentation.
> But the effect is just to let some things work that otherwise would be
> stopped.

But that is not enough. A language specification essentially provides
a vocabulary to describe interfaces between system components. It
talks about types, language objects that are in interfaces, which
parts of them are visible and what might be the permitted usage.

If that framework is missing you simply don't have the tools to
document the contract. 

Look at the empirical evidence how well components occuring "in the
wild" are documented in various languages. My impression is, that
languages with language mechanisms for modularization (like Ada,
Modula, Ocaml, ...) have a much better track record. YMMV.


>
>> Which just goes to show how evil that approach is.
>
> Nonsense. C++'s approach to identifying instantiations serves it
> excellently well in a variety of ways - traits classes,
> metaprogramming, optimized specializations, and best of all, automatic
> instantiation of function templates. 

You only have to do all that if you "instantiate" templates in header
files. If on the other side you have a separation into bodies and
interfaces there is a place where the package gets instantiated
(basically a place where the open parameters describing the data sizes
and stackframe layout are recorded). And that simply is the package
instance -- no need to generate code and no need to fold multiple
instantiation with the same parameters into one.

In Ada -- as I understand it -- an instantiation is simply identified
by the place where the

This approach is of cause not possible with header files (inclusion
vs. usage).

I do not want offer flame bait here, but ... -- I'm programming and
have been programming in a really wide range of languages, from
assembly to pure functional languages, and the older I become, the
more I'm appalled what a mess C++ is conceptually. 

You say, the right way in C++ is not types or interface constraints,
but "to handle it by documentation". I suggest, that the very, I'd
say, "openness" of most template definitions, make it just impossible
to define an abstract interface (i.e. to establish a contract between
component provider and component user).

Of course one can always employ "coding standards" top enforce the
required discipline. But that simply amounts to double work: First
write the component, then document it (or the other way
round). Instead of making a core part of the documentation into a part
of the language: The interface. And double work just results in the
"unnecessary" part being dropped under pressure.

I've compiled 20 years old Ada 83 code with Gnat after renaming just
some files. Have you ever tried to rebuild a C++-projekt from last
year or from 5 years ago?

> You are simply displaying the
> usual comp.lang.ada parochialism of "if Ada doesn't have it then you

No, I don't. Indeed, I can (in the mean time :-) point out very well,
where Ada misses the train for "the 21st century", except perhaps for
embedded programming.

But C++ simply is atrocious. Of course, now that there is so much code
around written in C++, a lot of people can earn their daily bread by
applying "social" and technical fixes to the language specification
bugs, like, coding standards, reading and applying the lessons from
Scott Meyers books and using memory debugger like valgrind. So
overall, and given the global employment situation it's perhaps a good
thing :-).

Not that coding standards are necessarily a bad thing: But they
shouldn't be cluttered with preaching ad-hoc fixes to something that
is actually a language problem. Dito valgrind is a good tool: But why
would I have to apply that to a desktop application?


> don't need it". A non-type template parameter can be a reference to a


The point is more about the things C++ doesn't have. :-)


> floating point object, by the way, so the lack isn't all that serious

>     extern double sin(double);
>     extern double const epsilon = 1e-6;
>     template <double (&F)(double), const double &E>
>     double integrate(double from, double to) { ... }
>     int main() { integrate<sin, epsilon>(0.0, 3.14); }


I fear you're proving my point here :-). I'm not talking about wether
things can be done at all. I'm mostly concerned how they are done, and
wether code written today can be read and understood in a finite
amount of time by the maintenance programmer who checks it out from
version control in 10 years time. 

Just to support my case: I think, the ARM and the Barnes book is good
enough to learn most of Ada if you got some background in "strongly"
statically typed languages (Pascal, ML, maybe Java) and some in
procedural languages (like C or Pascal). The Barnes book could be at
tiny bit more precise and complete in some points, but overall, it
makes a really good read.

C++ on the other side cannot be learned from the standard and book
X. Of course that might be my inability. The only good C++ book (IMHO)
are those "smart" hackish books like those of Scott Meyer. They make
good conversation pieces, but only highlight "intresting" corners of
the language. There is no book from which you can learn to read C++.

But as I said: YMVV.

Regards -- Markus