Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Brian Rogoff <bpr@shellx.best.com>]

On 7 Aug 1997, Fred Long wrote:
> Richard Irvine wrote:
> > 
> > For the benefit of the inexperienced and unperceptive amongst us (we
> > also have to earn a living) I would be fascinated to know what the real
> > professionals who read this newsgroup consider their favourite Ada
> > "warts" and their strategies for dealing with them.
> 
> John Barnes gave a talk at an Ada Uk Conference a few years ago
> entitled (something like) "Removing Ada's Warts".  I think it was
> published in Ada User.  (Sorry, I don't have the exact reference to hand.)

I'd be interested in reading it, if you can dig up the reference. Another 
good source (IMO of course) for Ada flaws is at 

	ftp://ftp.netcom.com/pub/hb/hbaker/

where several of the papers discuss memory management in Ada, and point out 
numerous flaws (of varying severity) in the language. My "favorite" one is 
this (from "Safe and Leakproof Resource Management using Ada83 Limited
Types", among others)

	The inability in Ada83 to export from the defining package of a
	private type a generic unit which takes a formal object of the
	private type is a very irritating restriction which appears to be
	due to a nasty pun in the Ada83 standard which makes formal objects
	appear to be real objects, at least in their syntax. Since real
	objects of the private type cannot be exported from the defining
	package due to a combination of other silly and irritating rules of
	Ada83, formal objects are also verboten. At the same time that Ada9X
	removes the restrictions on generic formal IN parameters, Ada9X 
	should also eliminate this restriction, so that more powerful 
	generic units can be exported by the package defining a private
	type. 

I posted an example of such a problem about a month ago. I am writing an 
STL like library in Ada which uses the "active" iterator approach. For
example, a generic Set could be written as 

generic
    type Element_Type is private;
    with function "<" ( Left, Right : Element_Type ) return Boolean is <>;
package AGL.Sets is
    type Set_Type is private;
    type Value_Type is private;
    function Is_Member ( Set : Set_Type; Key : Value_Type ) return Boolean;
    ... etc. ...
end AGL.Sets;

and a child package Iterators which instantiates its own textually nested 
generic signature packages corresponding to the kinds of traversal it
supports

generic
package AGL.Sets.Iterators is
    type Iterator_Type is private;

    function Start ( Set : Set_Type ) return Iterator_Type;
    function Finish ( Set : Set_Type ) return Iterator_Type;

    ... etc. ...

    -- ILLEGAL! These signatures can't be instantiated here!!!

    package Forward_Iterators is
      new AGL.Forward_Iterators(Value_Type, Iterator_Type, Value_Ptr,
                                Next, Get_Value, Set_Value, Get_Pointer);

    package Bidirectional_Iterators is
      new AGL.Bidirectional_Iterators(Value_Type,Iterator_Type,Value_Ptr,
                                      Next,Prev,Get_Value,Set_Value,
                                      Get_Pointer,"=");

end AGL.Sets.Iterators;
 
So what do we do about this problem? There are numerous workarounds, which 
involve creating a new package which instantiates the signature packages 
after Sets and Sets.Iterators. The choice is between instantiating the 
Sets and Sets.Iterators inside this new package, or passing in an
instantiated Sets (and maybe Sets.Iterators) as generic formal package 
parameters. A clumsy workaround IMO, but a workaround nonetheless.

I am curious about why this problem was not fixed in Ada 95. I've found
that null bodied "signature" packages are very useful for providing an 
interface to plug into generic package parameters, but the freezing rules 
force me into contortions like the above. If there were some way to 
interleave public and private sections in a package spec, these contortions 
would not be necessary. 

I should also note that while I agree with many of the criticisms made by 
Henry Baker in those papers, I don't share his very negative view of Ada. 
Scheme, SML, and Forth also suck, like Ada, but in different ways. 

-- Brian