ketil+haskell at ii.uib.no
Fri Mar 16 04:01:15 EDT 2007
Duncan Coutts wrote:
> On Thu, 2007-03-15 at 23:25 +0300, Bulat Ziganshin wrote:
>> the beauty of this proposal is that we can issue 3rd, 4th and any
>> other version based on real users feedback. including some module into
>> base means stopping of its active development, you can see the
>> situation with ByteString
> You keep saying this but I really do not think it is true.
One can hardly claim that active development stopped with ByteString's
inclusion in base!
On the other hand, I do think including it in base made contributing and
participating more difficult. I used to track the development version,
and my code could depend on specific versions, etc. Upgrading 'base' is
much harder, and I've basically given up on that, and just wait for the
next GHC snapshot, even if it means I have to implement 'groupBy'
Also, switching back and forth between being a separate package and a
part of base complicates dependencies: code that used to depend on the
'fps' package suddenly breaks when the package is part of 'base', and to
be compatible with both worlds, I need to juggle different cabal files.
In the end, I just made a dummy fps package satisfying the dependency.
> We probably will not get around to doing that before 6.6.1 since we're working on
> other things at the moment but the point is that we could.
You could change it, but it'd be hard for us mere users to pull it, test
it out, and perhaps revert to the old version. As a separate package,
it's just a few ghc-pkg's away. But regardless, if System.Filepath is
well defined enough that it won't be updated, it doesn't matter where it
Presumably, it wouldn't have to be so hard: base could conceivably be
more upgradeable, and cabal could grow backwards-compatibility functions
for packages that are split or merged.
(Are there other reasons for stuffing things in base than cyclic
dependencies with other modules in it, btw?)
More information about the Libraries