DData in hierarchical libraries
Robert Will
robertw at stud.tu-ilmenau.de
Fri Mar 19 09:13:21 EST 2004
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
More information about the Libraries
mailing list