base libraries

[Bulat Ziganshin]

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 at gmail.com