Adding System.FilePath

[Bulat Ziganshin]

Hello Neil,

Thursday, March 15, 2007, 10:54:03 PM, you wrote:

>> > Do you have a concrete proposal for what FilePath's should look like
>> > in Haskell'? "FilePath = String" is currently the least broken design,
>> > since no one has put forward a better one.
>>
>> does http://haskell.org/haskellwiki/Library/IO not count?

> It is a start, but not the whole answer. What is the type of readFile?
> Stringable a =>> a -> IO String ?

yes, if we say only about Filepath part and not about type for representing
file contents. another variant - provide some FilePath class. but
providing your module as separate library will allow to improve this
while keeping backward compatibility while including it into base
makes this scenario very problematic

> Stringable a =>> What about getContents? Can all this
> be implemented without breaking existing code? Does this stop people
> from chopping and changing at strings? Is that desirable?

the beauty of this proposal is that we can issue 3rd, 4th and any
other version based on real users feedback. including some module into
base means stopping of its active development, you can see the
situation with ByteString

> There are also lots of other questions, does this code want to go into
> base? Do we want to replace the existing code in base?

> Plenty of open questions, I suspect solving them all will take months
> at the very least...

i think that existing base should be conserved for keeping
compatibility with already developed apps/libs and new functionality
should be provided in form of cabal packages that can be easily
upgraded and even several versions can co-exist in one installation

then, functionality should be moved step-by-step from base to these
new packages. new functionality should go immediately into packages.
otherwise, for example, your shining new version of Cabal which uses
System.FilePath module, will be not compatible with ghc 6.6, and the
same will be true for all other apps/libs

then these packages will evolve. backward compatibility will be
provided by supplying old versions of libraries (via hackage or
preinstalled)

>Is breaking nhc/yhc for something as fundamental as open files acceptable?

i don't understood this question


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