DData in hierarchical libraries

[Daan Leijen]

> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>