
On Fri, 2007-03-16 at 14:03 +0000, Ian Lynagh wrote:
On Fri, Mar 16, 2007 at 08:07:24PM +1100, Duncan Coutts wrote:
suspect that we'd never have found these without the huge number of people using the lib that came from it being included as standard.
Please, please, please, packages can come "as standard" (i.e. be a core package) without having all their modules be part of the base package.
Yes.
As I've mentioned before, a reason to keep it in base in future is that it gives us the opportunity to rewrite programs that don't even import ByteString into more efficient versions, for example:
f . lines =<< readFile "foo"
to
f . map unpack . B.lines =<< B.readFile "foo"
(is B ByteString.Lazy here?)
Yes, that's the only way to preserve the semantics.
If we want to do that then we'd either need to put ByteString into base or split io out into its own package,
Aye, that'd probably work. I don't think the above transformation requires the list implementation be in the same package, since you could put rules into the bytestring/io lib that match on things defined in the list lib, eg: lines . B.unpack = map B.lines . B.lines
yes (and incidentally, the latter I think would be fantastic; looking only at the cabal dependencies and (transitively, admittedly) extensions you would be able to see if a library was able to do IO).
And if the dependencies (transitively) do not use the FFI which you can check by looking in the .cabal file and every module for OPTIONS pragmas. Not trivial but at least it could be automated. Duncan