Re: List Containers - The Road Ahead

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

"Ehud Lamm" <mslamm@mscc.huji.ac.il> 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