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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c5fe2cecfab19751 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-11 18:30:20 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news-out.visi.com!petbe.visi.com!skynet.be!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: ada_wizard@toadmail.com Newsgroups: comp.lang.ada Subject: Re: limited types in libraries Date: Thu, 11 Dec 2003 21:28:32 -0500 Organization: Cuivre, Argent, Or Message-ID: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: melchior.cuivre.fr.eu.org 1071196112 32852 80.67.180.195 (12 Dec 2003 02:28:32 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Fri, 12 Dec 2003 02:28:32 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.3 Precedence: list List-Id: Gateway to the comp.lang.ada Usenet newsgroup List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:3403 Date: 2003-12-11T21:28:32-05:00 Georg Bauhaus writes: > ada_wizard@toadmail.com wrote: > : Georg Bauhaus writes: > : > :> Sometimes I dearly wanted limited records but was defeated > :> by the library that could not store them (storing them was the > :> intention): > :> > :> type T(x: access D) is tagged limited private; > :> > :> I want x to be constant plus initialised once and for all, > :> so access discriminants are just fine, but T has to > :> be limited then. Which would have been o.K., but not every library > :> allows this. > : > : Just use the libraries that do; that's why there are more than one! > > What I'm doing is I'm using several, for some reaons, currently > in seperate configurations. Ok. Then you are in a good position to help start The Final Ada Library :). > One reason is that at the current (early) stage it helps me think > about what data I have, and how they interact, independent of the > implicit "design hints" that a library might entail. That's a good idea! > : Or, talk to the authors of the libraries that don't allow limited > : items, but do offer the functions you want, about improving them. > > If I had the money, I'd be glad give it to someone :-/ Sometimes all it takes is someone showing an interest. Most of these libraries were originally written for reasons other than money. Of course, money never hurts :). > (From what I see, there might be a few things to consider when a > container is to be used with limited types. If you want to reuse > code from the "non-limited" container, how does a "non-limited" > container implmentation depend on comparison and assignment of the > element type (and key type, possibly). True. Which is why SAL was designed from the ground up to support both limited and non-limited types, with the same generic containers. > What does it mean if a user supplied comparison function does not > fulfill a non-language requirement? (I think in Charles it turns out > to be a programmer's problem if he/she does not implement "=" and > "<" in a consistent manner for element/key. (That is also true for > STL's equivalents, IIRC.))) Hmm. I can't see why it would ever be ok to implement "=" and "<" in a non-consistent way. Certainly any subprograms provided by the user must meet the container's requirements. > : SAL (http://www.toadmail.com/~ada_wizard/) allows limited items, > : but is somewhat lacking in functionality compared to other > : libraries; want to help improve it? > > Improving container libraries looks like really hard and admirable > skillful work, therefore I don't feel like I can be of great > help. (Let alone time...) Well, it is certainly harder than just using a working one. But it is certainly worth doing. Adding missing functionality to a well-designed library is easier than starting from scratch. And, simply proving feedback and motivation to the authors might be enough. I know I'd be more willing to work on SAL if I knew people were using it. And finally, you should always spend some time challenging your skills; that's the only way to improve them :). > For example, when I ran into the above mentioned Iterator problem > when copying a (sorted) map, I found myself following paths deep > down into a red-black tree (implemented following the first edition > of Corman/Leiserson/Rivest is seems) and wondering why some pointer > was null, until I thought I had discovered that Assign (I think) had > not been done yet, it is commented. Hmm. If a subprogram is not implemented, it should raise an exception, not silently do the wrong thing. You can fix that much, at least. > Luckily I shouldn't have used assignment in the first place, so this > has actually helped me discover a "design bug" in my program :-) > However, to solve these kinds of problems in a library it takes a > programmer with more skills than I will every have, I'm afraid. Give it a try; you might surprise yourself. > But I will look at SAL (and the PragmARCs) when the program > has been assembled from its working pieces (in Charles and BC > configurations), in a second iteration to see whether the specs > are sufficiently abstract to allow an exchange of components. > I'll do that until there is a sufficient guarantee that some > library/ies will be provides with Ada :-) Excellent. If you can, please post a summary of your experience with these libraries. Maybe you'll inspire us to work together to do that One Final Library, after all ... -- -- Stephe ___________________________________________________________ This mail sent using ToadMail -- Web based e-mail @ ToadNet