On 8 Apr 2009, at 00:46, wren ng thornton wrote:
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 I find this a bit odd. Is this by design?
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.
To add my 2¢ to this one – The arguments for each one can be put across as this: • I prefer (M a b) -> a -> b, because we can do functional programming in it more easily. • I prefer a -> (M a b) -> b, because we can do stateful programming in it more easily. Perhaps we need to remember what kind of language Haskell is – yes it's an excellent imperative language, but when it gets down to it, it's functional, and maybe we should try to keep it that way. To add support to the other argument though – I think the stateful version reads better when used fully applied – it reads as lookup this key in this map. The reverse doesn't read so well in english, the best I can think of is, transform this map into a function and apply it, but that doesn't actually include the word lookup anywhere. Bob