Using Collections: ElemsView and KeysView
Hi I am using collections-0.3 and need to perform some operations on keys resp. values of a map. In the concrete implementations there are functions like 'elems' and 'keys' but there is no such thing in Data.Collections. Instead there are the types 'ElemsView' and 'KeysView' and functions 'withElems' and 'withKeys', but I have not the slightest idea how they are supposed to be used, there is very sparse documentation and no examples. I'd be glad for any hints. Cheers Ben
foldr on ElemsView is defined as such:
foldr f i (ElemsView c) = foldr (f . snd) i c
so, for example:
getElementList = toList . ElemViews
When I designed this code (some years ago), I didn't like the "fold" of Map to have the type:
fold :: (a -> b -> b) -> b -> Map k a -> b
This just doesn't make sense if we see maps as a collection of (key, value) pairs. (Indeed, toList :: Map k a -> [(k, a)]) In order to be consistent, but to provide an easy way to migrate to the new collection classes I was designing, I provided the ElemViews/KeyViews to "switch" to the former behaviour on a case by case basis. This also allows for definining optimized versions of foldr, etc. for each types that supports "Views", but this was tedious, so I never did it. GHC "RULE" pragma is probably better suited to the purpose anyway. As for the lack of documentation, everyone is very welcome to contribute ;) Cheers, JP.
Jean-Philippe Bernardy wrote:
foldr on ElemsView is defined as such:
foldr f i (ElemsView c) = foldr (f . snd) i c
so, for example:
getElementList = toList . ElemViews
Ok, thanks, this helps. I had forgot to look at the instances.
When I designed this code (some years ago), I didn't like the "fold" of Map to have the type:
fold :: (a -> b -> b) -> b -> Map k a -> b
This just doesn't make sense if we see maps as a collection of (key, value) pairs. (Indeed, toList :: Map k a -> [(k, a)])
In order to be consistent, but to provide an easy way to migrate to the new collection classes I was designing, I provided the ElemViews/KeyViews to "switch" to the former behaviour on a case by case basis.
I understand the motivation. Could you say something about the functions withElems and withKeys? Their types contain a mysterious type constructor 'T' that is not documented in the haddock docs. The source file says 'type T a = a->a' so I guess this is for cases where I want to 'lift' a function mapping e.g. keys to keys to a fucntion on Maps?
This also allows for definining optimized versions of foldr, etc. for each types that supports "Views", but this was tedious, so I never did it. GHC "RULE" pragma is probably better suited to the purpose anyway.
As for the lack of documentation, everyone is very welcome to contribute ;)
I'd love to, but my understanding is still somewhat limited... Cheers (and thanks) Ben P.S. The collections framework is great, but the type errors one sometimes gets are horrible. When I started to see whether I had understood what you wrote above I got: Couldn't match expected type `c' (a rigid variable) against inferred type `Str' `c' is bound by the type signature for `macros' at MacroSubst.hs:13:24 Expected type: (Str, c) Inferred type: (Str, Str) When using functional dependencies to combine Foldable (Data.Map.Map k a) (k, a), arising from the instance declaration at Defined in Data.Collections Foldable (Data.Map.Map Str Str) (Str, c), arising from use of `unions' at Gadgets.hs:95:13-30 When trying to generalise the type inferred for `macros' Signature type: forall c1. (Collection c1 String, Set c1 String) => Attributes -> c1 Type to generalise: forall c1. (Collection c1 String, Set c1 String) => Attributes -> c1
participants (2)
-
Benjamin Franksen -
Jean-Philippe Bernardy