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 better -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com