Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Tue, 9 May 2000, Richard D Riehle wrote:
> In article <t7og6gahgm.fsf@calumny.jyacc.com>,
> 	Hyman Rosen <hymie@prolifics.com> wrote:
> >Robert Dewar <robert_dewar@my-deja.com> writes:
> >> I am not at all convinced that automatic instantiation is
> >> a help to the reader and maintainer, on the contrary, it
> >> seems very awkward to have uses of templates not be visible
> >> from this point of view.
> >
> >I consider automatic instantiation of templates to be the compile-time
> >polymorphism equivalent of run-time dispatching on class-wide types.
> >When you make a dispatching call, you do not know what function you
> >are calling. Similarly, you should be able to call a generic function
> >without explicitly stating which one you are calling.
> 
> I wonder if there is a trade-off here between convenience and type
> safety.  Ada tends to lean heavily in the direction of safety,
> and automatic instantiation seems not quite as focused on that issue.

Overloading, runtime dispatching, and "use clauses" don't seem quite
as focused on safety either. The only way that automatic instantiation 
is troubling is that in the case of a language like C++ it is undecidable, 
I think in standard C++ they limit the depth of template expansion
(Hyman?) and I imagine a similar solution would be needed for Ada.  

> For example, the model for generic formal package parameters in Ada
> forces the designer to create a generic signature package corresponding to
> the parameter.  This makes automatic instantiation quite difficult to
> achieve, but has the benefit of pretty thorough compile-time evaluation
> of all the elements of the signature.  

Here are the rules for automatic instantiation proposed by Shen and
Cormack:

-- (1) Allow the name of a generic subprogram to appear wherever a
--     non-generic subprogram name is now allowed.
--
-- (2) Allow non-generic subprograms to overload generics
--
-- (3) Allow a subprogram component of a generic package to appear where
--     non-generic subprogram name is allowed.
--
-- (4) Allow generic package name to be specified in a "use" clause, thus
--     allowing subprogram components to be specified without
--     qualification according to rule (3)
--
-- (5) Allow some or all real parameters to be omitted in an explicit
--     instantiation

Packages in package parameters would not be inferred. 

> The goals of C++ are different from those of Ada.  If a programmer feels
> more comfortable with C++ goals, then C++ is a good choice.  If someone
> feels better with the goals of Ada, then Ada should be the choice.  

Programming languages don't have goals, people do. Languages are artifacts 
that can and should be discussed dispassionately. If a programmer believes
that a major feature of another language can be adapted to his preferred
language, why shouldn't he wish for change?

> Also,
> those goals are intended to satisfy different levels of confidence in the
> final product.  Would anyone who knows C++ well feel comfortable knowing the
> software for the avionics on their aircraft was programmed in C++?  
> Most of those I ask, say, "No way."   Ada is targeted to exactly that
> kind of application environment.  Scaling back a bit from that extreme,
> Ada still inspires a greater sense of confidence in its goals than C++
> when safety is an issue.  

"C++ is deficient with respect to Ada in the safety critical realm"
"C++ has automatic instantiation"
"Therefore automatic instantiation is deficient ..."

> Automatic instantiation does not inspire confidence, but that
> may not matter if a software failure does not kill or maim anyone.  

Your emotional rhetoric is unconvincing. Any language with type inference
has a kind of automatic instantiation and "lack of safety" is not a 
reasonable negative claim to make.

-- Brian