Daan: I take the liberty to "publish" this without knowing the exact terms of your license. Given the audience of this list, I think it will be no problem.

No problem, as long as the "final" version contains proper copyright/license information. Good work btw, I'll give detailed comments later. All the best, Daan.

Cheers, JP.

--------------- For easier review, a summary of changes follow. The source distribution also contains a diff.

* Scc module removed

More an algorithm than a data structure. Sort of (but not quite) redundant with SCC in Data.Graph

* renamed "single" to "singleton"

more explicit, more usual.

* removed find, favouring (!) and lookup.

avoids incoherency with Data.List.find

Map.find :: Map k v -> k -> v

List.find :: (a -> Bool) -> [a] -> Maybe a

* removed (<>), prefering append

More explicit. Besides, operators might be a problem in the current scheme of using modules qualified.

* rename "isEmpty" to "null"

to match List.null

* foldL, foldR, foldI -> foldl, foldr, foldi

to match Prelude.fold[lr]

* Added instances

* renamed "subset" to "isSubsetOf"

this matches isPrefixOf, isSuffixOf

* Added documentation / changed it to reflect changes incl. hints on how to use the module system.

----- I think I should explain why I wanted to change the interface of Maps.

Consider the type of these functions:

Set.fromList :: Ord a => [a] -> Set a Set.member :: Ord a => a -> Set a -> Bool Set.fold :: (a -> b -> b) -> b -> Set a -> b Set.filter :: Ord a => (a -> Bool) -> Set a -> Set a

Map.fromList :: Ord k => [(k, a)] -> Map k a Map.member :: Ord k => k -> Map k a -> Bool Map.fold :: (a -> b -> b) -> b -> Map k a -> b Map.filter :: Ord k => (a -> Bool) -> Map k a -> Map k a

With respect to fold and filter (and most functions), maps have the shape of collections of values. (The key type does not appear as such in the functions' signiatures)

Yet, a few functions break this conventions. For example, "member" tests the presence of a key, not a value.

This is justified by the implementation. I've come to think it is the way to go (given it is a "concrete" library). It makes me slightly uneasy that a few functions stand out, still.

__________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Thu, 26 Feb 2004, JP Bernardy wrote:

Set.fromList :: Ord a => [a] -> Set a Set.member :: Ord a => a -> Set a -> Bool Set.fold :: (a -> b -> b) -> b -> Set a -> b Set.filter :: Ord a => (a -> Bool) -> Set a -> Set a

Map.fromList :: Ord k => [(k, a)] -> Map k a Map.member :: Ord k => k -> Map k a -> Bool Map.fold :: (a -> b -> b) -> b -> Map k a -> b Map.filter :: Ord k => (a -> Bool) -> Map k a -> Map k a

With respect to fold and filter (and most functions), maps have the shape of collections of values. (The key type does not appear as such in the functions' signiatures)

Yet, a few functions break this conventions. For example, "member" tests the presence of a key, not a value.

This is justified by the implementation. I've come to think it is the way to go (given it is a "concrete" library). It makes me slightly uneasy that a few functions stand out, still.

Yes, the way you go looses some important laws of functional programming, e.g. prop_elements_are_member coll = all ('member'coll) coll where 'all' is defined via 'fold' as in the Prelude. A simple fix would be to change the type of 'member' and provide an additional function 'has_key' (or 'key_member') on Maps. Note also that the most general way is to view Maps as Collections of pairs, since than users can fold/filter/apply on the domain and range by composing their functions with 'fst' and 'snd'. Robert