Re: Anybody in US using ADA ? One silly idea..

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Hillel Y. Sims wrote:

> I can't really speak much for experience with generics in Ada, but since
> your original point was "Generics in any form is an illness of programming
> languages", let me try to address a few of your general issues w/r/t C++
> templates at least..
> 
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:av9egl$dd34q$2@ID-77047.news.dfncis.de...
>> In short generics is a meta language and no more than dressed macros used
> to
>> patch the source code.
> 
> They are much more than dressed macros; there is also a great deal of
> semantic context which is totally unavailable with macros.
> 
>>More elaborated:
>>
>> 1. Generics are static. You cannot have an object or dynamic-link library
> of
>> generics.
> 
> I have written and maintain a number of (large) dynamic-link libraries of
> instantiations of C++ templates.

Note that "instantiations of" is not what follows "of". A library of 
instantiations is not a library of templates.

>> 1.a. This kills code reuse at run-time.
> 
> This is therefore not necessarily true, based on the above.

No, you cannot reuse code across instantiations. Each of them is a macro 
expansion which has a separate body. Theoretically one could share generic 
bodies [at least in Ada it is sometimes possible], but practically it is 
not the case.

>> 1.b. You cannot have a true polymorphism with generics. [A fake, "static"
>> polymorphism was invented to hide the truth.]
> 
> Depends on your definition of 'polymorphism'. I have done some interesting
> things with compile-time polymorphism (inheriting a class from a template
> base class of the derived type). Anyhow, I see compile-time static and
> run-time dynamic polymorphism as complementary techniques which can
> provide a greater amount of flexibility in combination than either alone.

The time of binding (dispatch in a polymorphic call) is an *implementation* 
detail. If the type information is known at compile-time, then, at least in 
Ada, dispatch happens at compile time.

>> 1.c. You have geometric code size explosion if you consequently use
>> generics.
> 
> I guess this depends on the instantiation model and a lot of other
> variables. It is not inherently true with C++ templates.

If you bind at compile time then this is just a consequence.

>> 4. Generics are inconsistent with DbC. In C++ you just instantiate and
> pray.
>> In Ada it is better, but still you have reemergence of predefined
>> operations and other contract violations. The reason is clear, while the
>> core language operates with types and their relations, generics are sort
>> of: let's substitute one string for another and see if the result go
>> through the compiler. I think it was Kernigan and Ritchie who said that
>> preprocessor does not know C. Substitute generics for preprocessor and
>> language X for C.
> 
> Sorry, I don't really follow this point at all.

template <class X> class Y
{
public :
   X max (X A, X B) { if (A > B) return A; else return B; }
};

What ensures that X has ">"? There is no word about a contract, because 
"class X" means anything. In FORTRAN-IV you also can pass an INTEGER*4 
instead of REAL*4. I remember some people claiming that this is a very 
useful feature.

>> 5. Generics are unstructured and too powerful. They are comparable with
>> gotos. Gotos arbitrarely change control flow. Generics arbitrarely
>> produce new language objects. You can have a generic type, subroutine,
>> package, everything. The consequences of an instantiation is almost
>> impossible to predict. As with gotos, you should admit, that a program
>> with generics is very difficult to understand and maintain. [For C++
>> replace difficult to impossible, because of automated instantiation]
> 
> Again, I can't really speak of Ada generics, but I maintain several
> sizeable C++ libraries which make extensive use of templates. The amount
> of functionality provided is far greater with much fewer lines of code
> than the equivalent non-templated version would be. This complexity issue
> simply does not seem to be inherent in the manner in which you imply, at
> least with C++ templates.

Code density and simplicity of language constructs do not imply 
maintainability. What could be simplier than "JMP $1034"?

>> 6. Generics completely fall out of the language, because in fact they
>> form
> a
>> meta-langauge. A generic object does not exist for the core language.
>> What could be done with a generic object? The answer is: nothing. One
>> cannot pass a generic function as a parameter to a normal function. Even
>> a
> generic
>> parameter cannot be generic (:-)), only instances [= objects of the core
>> language] are allowed. So even as a meta-language, generics represent an
>> inconsistent one.
> 
> The biggest research/growth area in C++ these days seems to be templates
> and meta-programming. It is true there are some inconsistencies in the
> meta-language, but they don't prevent a lot of interesting programming
> from being done. If you have never seen the Boost Meta-Programming Library
> (http://www.boost.org/libs/mpl/doc/), you might want to check it out
> briefly; it demonstrates that quite a great deal can be done at
> compile-time with uninstantiated generic meta-objects.
>
> Anyhow, I will acknowledge that there are issues which need to be
> addressed/understood for successful use of generics/templates, and some of
> your points may be more oriented toward Ada than any other language, but I
> remain fully unconvinced that true generics (not glorified macros) are
> inherently a bad idea in any particular programming language.

A need in a meta language indicates that the core language is incomplete. 
Then the question is only whether this incompleteness is inherent or not. 
As long as the former is not proved I will claim that we do not need a meta 
language.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de