yes I agree. It seems to be mentioned here too http://www.haskell.org/haskellwiki/Parameter_order On Wed, Apr 8, 2009 at 12:38 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Wed, 8 Apr 2009, Peter Verswyvelen wrote:

These functions have their arguments reversed when compare to e.g. Map

...

For example

Data.HashTable.lookup :: HashTable key val -> key -> IO (Maybe val)

Data.Map.lookup :: Ord key => key -> Map key val -> Maybe val

For my taste, Data.Map.lookup has the wrong parameter order, since I often need the same Map with different keys and not vice versa. The HashTable.lookup parameter order can also be read as mapping a Map to the function it represents. I mean (HashTable key val) and (Map key val) represent functions of type (key -> val) and you can write: Data.HashTable.lookup :: HashTable key val -> (key -> IO (Maybe val))

http://www.haskell.org/haskellwiki/Parameter_order

On Wed, Apr 8, 2009 at 12:46 AM, wren ng thornton wrote:

As a design issue, I think the dominant order is better for partial application since they make good arguments to Control.Monad.State.gets and similar state-like HOFs. Considering the IO ugliness of HashTable, Jason Dagit may have a point though. As I recall, this discussion has lead to flame wars in the past.

Okay. I guess there's no clear winner here when it comes to argument order. And no need to waste energy on another flame war :-)

Jason Dagit wrote:

Peter Verswyvelen wrote:

...

wren ng thornton wrote:

...

As a design issue, I think the dominant order is better for partial application since they make good arguments to Control.Monad.State.gets and similar state-like HOFs. Considering the IO ugliness of HashTable, Jason Dagit may have a point though. As I recall, this discussion has lead to flame wars in the past.

Okay. I guess there's no clear winner here when it comes to argument order. And no need to waste energy on another flame war :-)

Especially here with Haskell. Just use flip if the arguments come in the wrong order.

I gotta say, I do enjoy the natural transformations Foo a b -> (a -> b) though. Perhaps Data.Map is right to have both lookup and (!)--- even though everyone's abandoned that due to the ugliness of qualified symbolic names. Is there a class somewhere which provides co-arr? There'd be a lot of instances for it[1]. Though the proper abstract nonsense should allow defining Foo a b -> F(a -> G b) for F and G other than Id (namely IO and Maybe for the functions under discussion). The problem here is the same as the (>>=) vs (=<<) issue for monads. On the one hand there's a pipelining or concatenative idiom, and on the other hand there's an applicative idiom. Both are declarative, both are functional, and both are (under different circumstances) natural. Yet we don't have a general solution for incorporating both styles, other than relegating one style to using flip everywhere. Hence the flames, since everyone wants to paint their own bikeshed, and noone wants to be a second-class citizen. [1] http://haskell.org/hoogle/?hoogle=a+b+c+-%3E+%28b+-%3E+c%29 -- Live well, ~wren

wren ng thornton writes:

...

Data.HashTable.lookup :: HashTable key val -> key -> IO (Maybe val) Data.Map.lookup :: Ord key => key -> Map key val -> Maybe val

I'd guess it's due more to antiquity than to intention.

I am fairly sure that FiniteMap, which preceeded Data.Map, had the same parameter order as HashTable. -k -- If I haven't seen further, it is by standing in the footprints of giants