[m-dev.] Multi_map: alist interface strange.

Douglas Michael Auclair dauclair at hotmail.com
Sun Aug 18 05:00:25 AEST 2002

Dear all,

The interface predicates in the multi_map module for assoc lists are 
strange.  An alist is a list of keys to values, but the interface predicates 
expect an input, or output, alist to be a list of keys to a list of values.  
This assumption goes against one of the primary reasons for having an alist: 
  multiple entries of the same key in the alist are allowed.

The problem is this.  If I have received an alist that looks like the 

[[3|Datum1], [4|Datum2], [5|Datum3], [4|Datum4], [3|Datum5], [4|Datum6], 
[5|Datum7], [4|Datum8]]

I'm then forced to parse and to collect same-key data together ... but 
that's the purpose a multi-map -- to eliminate this grunt-work from the 
user.  Similarly, when I receive an alist from another data structure type, 
I expect a one-to-one mapping between the key and the value, but multi-map 
transgresses here, too.  As a user of alists, I find these contrary 
assumptions distressing.

This problem ties in with the bug for multi_map__from_corresponding_lists/3 
I wrote to this list earlier.

I propose, then, that the alist interface predicates be changed to the 
following form:

from_assoc_list(assoc_list(K, V), multi_map(K, V)) and
to_assoc_list(multi_map(K, V), assoc_list(K, V)),

and that the multi_map__from_corresponding_lists/3 behavior be modified so 
that it allows the input key list to have multiple entries of the same key 
without writing over data.

If approved, you can also give me access to the sources, so I can affect 
this change, if you wish.

Doug Auclair

Send and receive Hotmail on your mobile device: http://mobile.msn.com

mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list