On Thu, 11 Mar 2004 09:56:45 +0100, Johannes Waldmann wrote:

* nice work. I might start using it (instead of Data.FiniteMap) just because the function names look better :-)

Thanks.

* argument ordering: the existing Data.FiniteMap mostly has f :: FiniteMap -> ... -> FiniteMap while the proposal uses f :: ... -> FiniteMap -> FiniteMap

I think the Edison guidelines are quite nice: http://www.haskell.org/ghc/docs/edison/users004.html#toc10

Did you follow them? What exceptions?

I did not follow the Edison guidelines, nor the GHC "guidelines". I tried different variations but in the end I sticked to the most consistent set I could think of: 1) The structure (i.e. Map, Set, Queue) is always the last argument. 2) All operations are left-biased. I noticed that the last point is rather important, it means that "insert key x map" will replace the current value of "key" with "x" if it is already present, and that "union map1 map2" will prefer elements of "map1" instead of "map2". Note that the GHC FiniteMap implementation is ambigious about its bias and the bias is documented per function (note: a thing that may bite us in particular is that GHC "plusFM" is right-biased and can thus not be replaced by DData "union" with a search-and-replace.) However, I do not have a strong opinion about this and maybe the Edison guide lines are better. However, I do believe that a "bias" rule like (2) is very important when you are using the library. A strong rule like (1) is maybe less convenient for fulltime users (especially in the context of partial applications), but much easier for sporadic users.

* types: some functions are not declared at their most general type (I checked by commenting out the decl. and asking ghci)

This was by purpose, for example:

difference :: forall a1 k a. (Ord k) => Map k a1 -> Map k a -> Map k a1

It is kind of strange to take the difference between to maps with different elements, so I thought it better to disallow that situation. However, it is a bit 1984 to disallow it, and I may be wrong here. All the best, Daan.