Norbert Zeh writes:

One way to "fix" this would be to expect everyone running darcs xmonad to use the latest version of containers, but I'm not sure that's reasonable. Another alternative I see is to use CPP to include home-brewed versions of filter and breakl directly in GroupNavigation if the detected GHC version is < 6.12. Any suggestions from the people with authority (Don, Spencer, Adam, ...) as to what the preferred solution is?

The source of filter seems to be straightforward; maybe just copy it directly and not worry about CPPing? -- | /O(n)/. The 'filter' function takes a predicate @p@ and a sequence -- @xs@ and returns a sequence of those elements which satisfy the -- predicate. filter :: (a -> Bool) -> Seq a -> Seq a filter p = foldl (\ xs x -> if p x then xs |> x else xs) empty -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Adam Vogt [2010.05.11 1308 -0400]:

* On Tuesday, May 11 2010, Ivan Lazar Miljenovic wrote:

...

Norbert Zeh writes:

...

One way to "fix" this would be to expect everyone running darcs xmonad to use the latest version of containers, but I'm not sure that's reasonable. Another alternative I see is to use CPP to include home-brewed versions of filter and breakl directly in GroupNavigation if the detected GHC version is < 6.12. Any suggestions from the people with authority (Don, Spencer, Adam, ...) as to what the preferred solution is?

The source of filter seems to be straightforward; maybe just copy it directly and not worry about CPPing?

-- | /O(n)/. The 'filter' function takes a predicate @p@ and a sequence -- @xs@ and returns a sequence of those elements which satisfy the -- predicate. filter :: (a -> Bool) -> Seq a -> Seq a filter p = foldl (\ xs x -> if p x then xs |> x else xs) empty

Right, so we could substitute the definitions when the the containers version that cabal specifies is too low (see attached ugly patch).

containers-0.3.0.0 should build with older GHCs. It would be much easier to manage if we could just require a newer containers: maintaining those macros is a fair amount of work. Is that allowed, or is it too great a concern that this adds one more dependency to fetch for users with older GHCs?

Indeed, requiring the newer containers is the cleanest solution, but your last question is exactly the concern I had about this solution. Don, Spencer: any opinion on this one? N.

* On Wednesday, May 12 2010, Ivan Lazar Miljenovic wrote:

Adam Vogt writes:

...

containers-0.3.0.0 should build with older GHCs. It would be much easier to manage if we could just require a newer containers: maintaining those macros is a fair amount of work. Is that allowed, or is it too great a concern that this adds one more dependency to fetch for users with older GHCs?

It isn't: Cabal is the only library that comes with GHC that you should upgrade as otherwise you get diamond dependency problems (which is why "cabal upgrade" is currently disabled).

Well supposing that xmonad-core and xmonad-contrib are built with the same containers version, and user's configs are compiled with -package (which isn't done), keeping two versions can work, though there will be issues to use say a Map produced by functions from another library (though I don't believe this happens in user configs). So maybe it could be made to work for most configs, but it looks like conditional compilation (or just sticking to the containers-0.2 subset of the api) will probably cause less trouble. -- Adam