[Haskell-cafe] can't build haxml under ghc 6.7, says HughesPJis hidden... but ghc-pkg doesn't say it's hidden...

[Claus Reinke]

>> For now, we just edit .cabal files when transporting code between GHC
>> versions...
> 
> Just for information, the HaXml darcs repo has recently adopted the
> solution of containing two .cabal files, one for ghc-6.6.x, and the
> other for the split-base packages (>=ghc-6.7).  The only difference is
> the build-depends line, which is now as follows:
> 
>    build-depends: base, haskell98, polyparse, pretty, fps
> 
> But if you have collected the earlier release HaXml-1.13.2 from hackage,
> then you can omit both 'polyparse' and 'fps' dependencies.  ('fps' will
> shortly be changing to 'bytestring' in any case...)

would it be possible to put more emphasis on continuity in 
haskell (just as there should be an emphasis on portability;-)?

when changing language, tools, or libraries in a way that breaks
existing programs, deprecating the old api for one version before
removing it is rarely sufficient, and leads to breakage rather than
hackage..

it would be nice if anyone thinking of breaking a public api
would spend some thought on code transitions. be it by 
providing compatibility adapters, or code transformations, 
or whatever.

users should not be so accepting of breaking changes, either.
yes, you may be able to work around the issues, but what good
are package managers if they only work with workarounds?

in this particular case, the rest-base simply doesn't do what
base did, so it shouldn't be named base. instead, perhaps 
there should be a virtual base package that only tracks the 
dependencies needed to support the old base? similarly for
the now-its-in-now-it-isnt fps/bytestring.

:-)

claus