[Haskell-cafe] Functions from Data.Hashtable

wren ng thornton wren at freegeek.org
Tue Apr 7 19:41:56 EDT 2009

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,

More information about the Haskell-Cafe mailing list