base libraries

Bulat Ziganshin bulat.ziganshin at
Thu Nov 23 10:42:14 EST 2006

Hello Neil,

Thursday, November 23, 2006, 4:33:57 PM, you wrote:

>> * core libs are installed as a aprt of ghc installation process. these
>> includes libs that are either ghc-version dependent (base/stm/th) or
>> required in process of installation of other libs (cabal, filepath,
>> filesystem?)

> Yep, that seems a more sensible definition of core. All core libraries
> MUST be available to all Haskell implementations. If/when that
> direction is taken, things can be split out, but for the moment this
> is a future thing.

it's no more future than inclusion of module in Base lib. we can
discuss this just now and if GHC HQ will decline such proposal, i will
agree that it may be better to include FilePath module in Cabal lib

>> > For FilePath there is also the specific issue that its actually
>> > required by base (see System.Directory.Internal),
>> and you want to replace this module with your own, raising
>> incompatibility problem again?

> I don't want to replace it now, but this might be something for the
> future, if the code is examined in detail, and seems to the same
> thing.

so your argument for inclusion it into the Base is to have *two*
modules here with overlapping functionality? :)  someone who will does
this optimization task may follow the same recommendations and move
existing System.Directory modules into the FilePath lib. anyway, it
will be better because it guarantees to not introduce
backward-incompatible changes in non-upgradeable Base lib

>> backward-incompatible changes. anyone requiring just the old
>> functionality then can install FilePath 2.10 and be happy,
>> irrespective of Base version he uses

> I don't want to evolve or enhance FilePath, I want it to reach a stage
> where it provides a useful set of operations, and freeze it. I also
> don't want to pick up the responsibility for maintaining the File
> related chunks of base :)

i always suspect that base inflated so much just because lack of
responsibilitiness in some haskellers :)  of course, it's much easier
to put anything you can write here and don't think how it can be used

and, while you can't imagine progress of FilePath module, i can do.
what you propose to do in this case - have two filepath modules, one
in the base and one in other place? or make incompatible changes in Base?
to be concrete, i want to make these functions polymorphic and be able
to work on various string-alikes

experience shows that even such well-established modules as Data.List
are sometimes changed. so, while your work is great, this don't mean
that it will be frozen and can't be replaced with something even

Best regards,
 Bulat                            mailto:Bulat.Ziganshin at

More information about the Libraries mailing list