[Haskell] base libraries

[Bulat Ziganshin]

Hello Chris,

Thursday, November 23, 2006, 1:20:51 PM, you wrote:

>> example, it includes 2 of 4 regexp libs? at last end, we can learn
>> that this is the list of libs required to build ghc itself!

> Some of the other regex-* libraries are interfaces to c-library backends (pcre
> and tre) and it is not GHC's place to come with copies of those libraries.  But
> GHC used regex internally, so it must come with at least a single backend.

what means "used internally"? you mean compiler sources? i don't see
reasons why each copy of ghc should be able to compile ghc itself

> The regex-* modules that are installed with GHC are not in the "base" package.
> They are in "regex-base" and "regex-posix" and "regex-compat" because I took
> excellent design advice and finely split the modules.  I see no reason one could
> not by able to upgrade these on top of the GHC versions.

of course. i say here about base libraries, i.e. those strange set
shipped with ghc 6.6. i argue to including here not only regex-*
which is excellent work, but other widely used libs too

> You are correct: as far as I can see the only module that is in "base" which
> might need to be split out is Data.ByteString.  The same may or may not apply to
> Data.Sequence.

ByteString is most offending example, but not alone. what is the base
library now? is it about data structures, I/O, concurrency or monads?
there is no answer - this lib contains everything developed by peoples
having accounts at darcs.haskell.org. why it's impossible to use
Applicative class with ghc 6.4? because Ross Paterson was so kind to
include this in a base lib. why peoples get a problems with their
mutable arrays in 6.6? because arrays interface was changed and there
is no way to use old lib in 6.6. why ForeignPtrs in 6.4 are slow?
because it's a part of base lib and it's impossible to use faster
ForeignPtr implementation without upgrading entire compiler. and so
on, so on

inflation of base library and inability to upgrade it have cumulative
effect. i think that our ultimate goal is a set of ghc-independent
concrete libs: arrays, control, files, concurrency... and any step in
this direction will simplify upgrading to next ghc version

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com