From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Warts was Re: The stupidity of all the Ariane 5 analysts. Date: 1997/08/07 Message-ID: #1/1 X-Deja-AN: 262770665 References: <33C835A5.362A@flash.net> <33CC0548.4099@flash.net> <5qitoi$fdv$1@news.irisa.fr> <33CD6512.2404@flash.net> <01bc92e6$7a6f9e40$287b7b7a@tlo2> <33CEAF05.6389@flash.net> <33D2827B.41C67EA6@eiffel.com> <5qucs7$jie$3@flood.weeg.uiowa.edu> <33D3F2CB.61DC@flash.net> <5r4952$nca$1@flood.weeg.uiowa.edu> <33DE3CC7.2294@gsg.eds.com> <33E07E29.69CB@eurocontrol.fr> <33E7B7A5.56FF@gsg.eds.com> <5scqlr$ju@news.sei.cmu.edu> Newsgroups: comp.lang.ada Date: 1997-08-07T00:00:00+00:00 List-Id: 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