Adding System.FilePath

[Duncan Coutts]

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