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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c8458572136e831 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-08 13:51:38 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!ppp-2-11.cvx2.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: List Containers - The Road Ahead Date: Thu, 8 Nov 2001 21:32:29 -0000 Message-ID: <9seup5$12h0ar$4@ID-25716.news.dfncis.de> References: <9sdpku$eu2$1@news.huji.ac.il> NNTP-Posting-Host: ppp-2-11.cvx2.telinco.net (212.1.141.11) X-Trace: fu-berlin.de 1005256294 36208987 212.1.141.11 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:16100 Date: 2001-11-08T21:32:29+00:00 List-Id: "Ehud Lamm" wrote in message news:9sdpku$eu2$1@news.huji.ac.il... > ... > - Refernce implementations of the specs. These can be contributes by anyone, > but must adhere to the spec. Trying to provide implementations, is the sure > way of finding mistakes in the specs... Absolutely right. Excellent idea. > - Test code, that uses the containers. If the specs are useful, it should be > easy enough to take some code you have that uses lists, and make it use > "standard" list package. As well as "How To" documentation, giving clear and simple guidelines on how (best) one would use the proposal. > That's for lists. > To see how the universal the design can be, can someone propose a > Map/Dictionary Strawman? My proposal already covers (a basic abstract framework for) content-addressed storage (i.e. it has an index or key type as well as a data type). However, I recall finding certain corrections that need to be made (and some improvements). In general (and therefore in the abstract), any normal container can be made into a map (mapping say type T1 to type T2) container by containing a T1-T2 duple type: type T3 is record D1: T1; D2: T2; end record; and then instantiate the container package with type T3. Basing things on my proposal now, this points the way to proceed for special mapping packages: generic type Source_Type is ...; type Target_Type is ...; package Magic_Mapping is type Mapping_Type is ...; -- concrete type ... -- operations on Mapping_Type type Mapping_Pair is record From: Source_Type; To: Target_Type; end record; package Pair_Iteration is new Iteration(Mapping_Pair); type Pair_Iterator (Mapping: access Mapping_Type) is new Pair_Iteration.Sequence_Reproducer with private; procedure Open (Iterator: in out Pair_Iterator); procedure Close (Iterator: in out Pair_Iterator); ... end Magic_Mapping; This illustrates the alternative technique of an implementation providing an auxilliary iterator type (rather than the main container type being itself an iterator). Procedure Open might lock the mapping associated with its iterator parameter, preventing it from being modified during the iteration; procedure Close would then unlock the mapping, permitting it to be modified again. However, this design is certainly not the only one. Note how this package exports an instantiation of Iteration. This trick has both advantages and disadvantages, but it means the user (of the package) has only one instantiation to do: package Alchemy is new Magic_Mapping(Chemical_Element,Chemical_Element); The appropriate iterator type is then immediately available for use: Melting_Pot_1: aliased Alchemy.Mapping_Type; Iterator: Alchemy.Pair_Iterator(Melting_Pot_1'Access); Pair: Alchemy.Mapping_Pair; ... Open(Iterator); while not End_of_Data(Iterator) loop Read(Iterator,Pair); if Pair.From = Lead and Pair.To = Gold then raise The_Roof; -- eureka! end if; end loop; Close(Iterator); ... You get the idea (I hope). I have illustrated a concrete mapping (package) here; it may well be beneficial to devise an abstract mapping (package) on which to base the concrete ones. > I apologize for all the typos in my original message. Taht's prefetcly alirhgt, Ehdu. We undrestnad. }--| cheers ;-) -- Best wishes, Nick Roberts