Hello Neil, Thursday, November 23, 2006, 1:23:19 PM, you wrote:
so, the only reason why you want to include FilePath in Base is to make it available for any haskeller? i consider this as one more argument for GHC HQ to accept my proposal ;)
"on windows, it should be a part of monolithic installer while on unixes these libs may be a separate packages, but porters should ensure that they ported all these libs too"
To me that implies that on unixes they will all be available to install, but not all be installed by default. That means they can't be used in cabal.
i'm not a unix guru so i missed this point :) but this seems to me as an argument to include filepath in a set of core libs, not a Base lib. i should reformulate this paragraph of my proposal: * 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?) such decision will kill both hares - it will allow to use filepath lib in setup scripts and cabal itself and at the same time it will allow to install additional versions of filepath lib to use in user projects
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? how about going in opposite direction - moving filesystem-related modules from Base into your library? say, current version of Base is 2.0. you can release Base 2.1 + FilePath 2.1 which provides the same functionality as Base 2.0, only with modules rearranged. and then you can go to release FilePath 3.0, 4.0 and so on which may have backward-incompatible changes. anyone requiring just the old functionality then can install FilePath 2.10 and be happy, irrespective of Base version he uses -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com