On Mon, Sep 27, 2010 at 3:16 PM, Felipe Lessa wrote:

...

adjustM f k m == liftM (\x -> insert k x m) (f $ lookup k m )

This suggests that you don't need the Monad constraint, only Functor.

That's just because I hid the case where `lookup k m` fails. I'm sure looking at other desirable *M functions would reveal similar issues with using Functor alone. adjustM f k m == case lookup k m of Just x -> liftM (\new -> insert k new m) (f x) Nothing -> return m translating this to Functor: adjustF f k m == case lookup k m of Just x -> fmap (\new -> insert k new m) (f x) Nothing -> ??? -- perhaps "pure m" thus adding another constraint, but how would that be better than Monad for most people? Cheers, Thomas

On Tue, Sep 28, 2010 at 12:08 AM, Thomas DuBuisson wrote:

If the number of functions becomes a concern we can be effective and still conservative.  Take Data.Map as an example, we can make updateLookupWithKeyM and omit alterM, alterWithKeyM, insertLookupWithKeyM, etc as those can be built using updateLookupWithKeyM - no power lost.  This strategy might cut the number of functions down from ~2 dozen to a bare handful ( I expect a 'map' variant will be sensible, probably one or two others).

That sounds sensible. It would be great if someone could write a benchmark to check if the more general function has the same performance as the more specialized ones. It's really unfortunate that we have with and without key versions of everything. It forces you to have 8 (!) copies of higher order functions e.g. foldl foldlWithKey foldlM foldlWithKeyM foldl' foldlWithKey' foldlM' foldlWithKeyM' if you want to be consistent. -- Johan

On Tue, Sep 28, 2010 at 08:35:30AM -0400, Jean-Philippe Bernardy wrote:

On Tue, Sep 28, 2010 at 12:08 AM, Thomas DuBuisson wrote:

...

If the number of functions becomes a concern we can be effective and still conservative.  Take Data.Map as an example, we can make updateLookupWithKeyM and omit alterM, [***]

alter is the most powerful function. It can perform an insertion, while updateLookupWithKey cannot.

I don't understand why the number of functions is such an issue. To me, ease of use is more important. For example, (assuming the performance is, or could be made, the same), would Data.List be improved by removing concat and map, as they can be written as (concatMap id) and (concatMap . (return .))? Thanks Ian

On Tue, Sep 28, 2010 at 9:57 AM, Ian Lynagh wrote:

I don't understand why the number of functions is such an issue. To me, ease of use is more important.

But more functions hurts ease of use! An API gets harder to grasp the more functions it has and knowing which function to use gets harder when the number of functions increases. OO map data type get away with about 10-15 functions, we have 150! I've written about this topic before on haskell-cafe. That post contains a somewhat more thorough arguments for not adding too many functions to APIs. Let me know if you can't find it. (There is also an maintenance cost, but it's not as important as the cost to API users).

For example, (assuming the performance is, or could be made, the same), would Data.List be improved by removing concat and map, as they can be written as (concatMap id) and (concatMap . (return .))?

If we would remove any of these three functions it would be concatMap as it's a simple function composition of the concat and map! The only reason I can see for having concatMap is that it's >>= for lists. -- Johan

On 09/28/10 15:14, Ian Lynagh wrote:

I'm not convinced it's harder for an expert to write with, and I think a beginner will generally prefer having the functionality they need directly available, rather than having to compose functions together.

As a beginner, I liked the practice of having to compose functions together. It helped me grasp the ways in which that *can* be done. (This doesn't seem to me like a convincing argument to avoid the more functions. Just thought it was a doubt worth hearing.)

Johan Tibell wrote:

Thomas DuBuisson wrote:

...

Is there a reason not to have monadic version of the functions in containers? I've a need for functions of type:

Ack! Haskell needs effect polymorphism. The API already has 150 functions. How many more do we need to add if we want to cover all the monadic versions?

I think this problem should be solved by making the API more general/flexible, not by adding more specialized versions. For instance, the function focus :: k -> Map k a -> (Maybe a, Maybe a -> Map k a) that returns the element together with its context ("map with a hole where the element was") can express all the insert, update etc. functions as well as their monadic versions. You can also use it for lookup , though that has a performance cost since the context is generated and then discarded. Of course, there ought to be a optimization pass that can catch these situations with a few hints and eliminate the superfluous work. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com