ANN: Simple components v 1.3

ANN: Simple components v 1.3

[Dmitry A. Kazakov]

This release includes generic maps (associative arrays)

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: ANN: Simple components v 1.3

[Preben Randhol]

On 2004-01-03, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> This release includes generic maps (associative arrays)

Sorry, but where?

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: ANN: Simple components v 1.3

[Dmitry A. Kazakov]

On Wed, 14 Jan 2004 12:06:50 +0000 (UTC), Preben Randhol
<randhol+valid_for_reply_from_news@pvv.org> wrote:

>On 2004-01-03, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> This release includes generic maps (associative arrays)
>
>Sorry, but where?

http://www.dmitry-kazakov.de/ada/components.htm

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: ANN: Simple components v 1.3

[Mats Weber]

In article <75ga001eokc2r1aijtvu9d70ck3i6j1p0m@4ax.com>,
 Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

>>> This release includes generic maps (associative arrays)

>http://www.dmitry-kazakov.de/ada/components.htm

I have been working on this (generic maps) for quite a while (and a long 
time ago). What I came up with is that the generic formal key type must 
be limited private and unconstrained (<>) for the component to be 
useable in most situations.

Here is the generic formal part of my version of maps:

generic
   type Key_Type (<>) is limited private;
   type Item_Type is private;
   with function Key_Of (Item : in Item_Type) return Key_Type;
   with function "=" (X, Y : Key_Type) return Boolean is <>;
   with function "<" (X, Y : Key_Type) return Boolean is <>;
   type Count is range <>;    -- must include 0
package Bags is
   ...

The big differences is that there is no constraint on Key_Type and that 
the key is part of each item and is extracted from it with the generic 
formal function Key_Of. 

For instance, you can have Key_Type => String, with the above, which you 
cannot do with your version.

Re: ANN: Simple components v 1.3

[Dmitry A. Kazakov]

On Thu, 15 Jan 2004 15:01:05 +0100, Mats Weber <matsw@bluewin.ch>
wrote:

>In article <75ga001eokc2r1aijtvu9d70ck3i6j1p0m@4ax.com>,
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>>>> This release includes generic maps (associative arrays)
>
>>http://www.dmitry-kazakov.de/ada/components.htm
>
>I have been working on this (generic maps) for quite a while (and a long 
>time ago). What I came up with is that the generic formal key type must 
>be limited private and unconstrained (<>) for the component to be 
>useable in most situations.
>
>Here is the generic formal part of my version of maps:
>
>generic
>   type Key_Type (<>) is limited private;
>   type Item_Type is private;
>   with function Key_Of (Item : in Item_Type) return Key_Type;
>   with function "=" (X, Y : Key_Type) return Boolean is <>;
>   with function "<" (X, Y : Key_Type) return Boolean is <>;
>   type Count is range <>;    -- must include 0
>package Bags is
>   ...
>
>The big differences is that there is no constraint on Key_Type and that 
>the key is part of each item and is extracted from it with the generic 
>formal function Key_Of. 
>
>For instance, you can have Key_Type => String, with the above, which you 
>cannot do with your version.

Isn't it same as to have just set rather than map? I have Generic_Set:

generic
   type Object_Type is private;
   Null_Element : Object_Type;
    ...
   with function "<" (Left, Right : Object_Type) return Boolean is <>;
   with function "=" (Left, Right : Object_Type) return Boolean is <>;
package Generic_Set is

Here elements are comparable without mentioning any key type.

I have added Generic_Map only after realizing that sometimes it is
necessary to have different ordering strategies for the same object
type and that the key is not always deducible from the object it
points to.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: ANN: Simple components v 1.3

[Mats Weber]

In article <629d00tlqvu326hi1vsomlmnvkobvbc0bl@4ax.com>,
 Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

>Isn't it same as to have just set rather than map? I have Generic_Set:
>
>generic
>   type Object_Type is private;
>   Null_Element : Object_Type;
>    ...
>   with function "<" (Left, Right : Object_Type) return Boolean is <>;
>   with function "=" (Left, Right : Object_Type) return Boolean is <>;
>package Generic_Set is

I think not, because with maps, you have to be able to extract an item 
given its key, which you cannot do with Generic_Sets as there is no key 
type. Following is the function that does that in my package:

   function Search (Key : Key_Type; Within : Bag) return Item_Type;
      -- Returns the first item in FROM that has a key equal to KEY.
      -- NONEXISTENT_KEY will be raised if no such item is
      -- found in the bag.

Re: ANN: Simple components v 1.3

[Jeffrey Carter]

Mats Weber wrote:

> I think not, because with maps, you have to be able to extract an item 
> given its key, which you cannot do with Generic_Sets as there is no key 
> type. Following is the function that does that in my package:
> 
>    function Search (Key : Key_Type; Within : Bag) return Item_Type;
>       -- Returns the first item in FROM that has a key equal to KEY.
>       -- NONEXISTENT_KEY will be raised if no such item is
>       -- found in the bag.

It should not be necessary for the component to know about the 
difference between keys and values. To my mind, a map is a way of using 
a searchable structure, such as a balanced tree or a skip list. For 
example, using PragmARC.Skip_List_Unbounded, one would define the 
Element type actual as

type Map_Data is record
    Key   : Unbounded_String;
    Value : Data := Null_Data;
end record;

Then the necessary comparison routines:

function "=" (Left, Right : Map_Data) return Boolean is
begin -- "="
    return Left.Key = Right.Key;
end "=";

function "<" (Left, Right : Map_Data) return Boolean is
begin -- "<"
    return Left.Key < Right.Key;
end "<";

After instantiating Skip_List_Unbounded, one can insert and search by key:

Key : constant Unbounded_String :=
    To_Unbound_String ("Your key here");

Thing : Map_Data := (Key, Some_Value);
Map   : Skip_List;
Found : Result;
...
Insert (List => Map, Item => Thing);
Thing := (Key, Null_Data); -- Value component not used in Search
Found := Search (Map, Thing);

if Found.Found then
    -- Do something with Found.Item, type Map_Data, which contains
    -- (Key => Key, Value => Some_Value)
end if;

-- 
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail
13

Re: ANN: Simple components v 1.3

[Dmitry A. Kazakov]

On Thu, 15 Jan 2004 17:22:33 +0100, Mats Weber <matsw@bluewin.ch>
wrote:

>In article <629d00tlqvu326hi1vsomlmnvkobvbc0bl@4ax.com>,
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>>Isn't it same as to have just set rather than map? I have Generic_Set:
>>
>>generic
>>   type Object_Type is private;
>>   Null_Element : Object_Type;
>>    ...
>>   with function "<" (Left, Right : Object_Type) return Boolean is <>;
>>   with function "=" (Left, Right : Object_Type) return Boolean is <>;
>>package Generic_Set is
>
>I think not, because with maps, you have to be able to extract an item 
>given its key, which you cannot do with Generic_Sets as there is no key 
>type. Following is the function that does that in my package:
>
>   function Search (Key : Key_Type; Within : Bag) return Item_Type;
>      -- Returns the first item in FROM that has a key equal to KEY.
>      -- NONEXISTENT_KEY will be raised if no such item is
>      -- found in the bag.

Mmm, one could use:

function Is_In (Container : Map; Element : Object_Type)
   return Boolean;

Actually here comes the motivation for maps from. I encountered that
it is too expensive in some cases to create a new object to be used in
Is_In. For example, when object is a handle to something large. So I
decided to make maps with keys completely separated from objects. Your
variant is somewhere in between, it is rather set than map. BTW, I
didn't care that String could not be used as a key, because I had
generic tables to deal with that
[http://www.dmitry-kazakov.de/ada/tables.htm] and I saw no other
interesting cases of unconstrained keys. 

-----------------
Some time ago I posted a proposal for proper constructors,
assignments, limited types initialization:

http://groups.google.com/groups?hl=en&lr=lang_en|lang_de|lang_ru&ie=UTF-8&selm=au9fm2%245kta0%241%40ID-77047.news.dfncis.de&rnum=1

That could help to solve the problem of creating unconstrained objects
from unconstrained generic parameters (with some extensions of
discriminants). Something like this:

generic
   type Key_Type (<>) is private;
   ...
package Foo is
   type Token (Constraints : Key_Type'Constraint) is record
      Key : Key_Type (Constraints);
      ...
   end record;

Here Key_Type'Constraint denotes an anonymous null-record type having
exactly same discriminants / bounds as Key_Type. Using this type as a
discriminant for Token one could constrain the Key component.

Interestingly, it seems that this would also allow to copy limited
unconstrained objects without having assignment. But I see no harm in
that.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de