System.FilePath Re[2]: ANN: HSH 1.2.0

[Bulat Ziganshin]

Hello Neil,

Tuesday, March 13, 2007, 12:24:42 PM, you wrote:

> These are all worth thing to do, but there are two different type of
> operations here - those that operate on filenames, and those that do
> IO. As Simon Marlow has previously said,  keeping these things
> separate is usually a good idea.

i don't see it that way. for me, there are plenty of APIs which are
sitting on top of each other:

* operations on String/ByteString/...
* class Stringable which provides uniform access to these operations
* FilePath module which operates on filenames represented in any Stringable form
* Directory module which works with filesystem using FilePath operations
* File i/o routines where open() uses Stringable again
and so on

what i propose is to detach middle layer (from FilePath to File i/o)
of this stack into one library. splitting may be different, the main
reason to propose this one is because there are at least 2 different
approaches to make buffering (Streams and SSC), but both should be
happy working via such low-leve i/o lib. we can also split this
functionality (FilePath, Directory, File, MappedFile) further to 2-4
libs, but i don't have any concrete reasons to propose it

i'm definitely against merging FilePath into base because this means
that it will be not available for applications until 6.8 arrives, and
make impossible to improve it without losing backward compatibility.
i've written about these problems in context of FPS library. now there
are updated versions of this lib that can't be used with 6.6 and
therefore lost for potential users. because i need improved version of
your module (with support for UTF8String), i definitely against
inclusion it into the base

> This also seems to be an attempt to replace type FileName = -
> something that is going to take much more work.

the beauty of idea is that you can roll out now FilePath 1.0 with just
a String support and when Stringabe support will be implemented, it
will become FilePath 2.0 release. It's impossible with Base because
there are no ways to distinguish between various versions of it nor
there is compiler-independent version evolution

> Rolling my FilePath code into this package is perfectly fine, but I
> think the FilePath operations specialised to String (as defined by
> Haskell 98)

and what? H98 libs are useless in real world

> are important to go into base, if for no other reason than
> without them Cabal cannot depend on them.

but we don't need to add operations required for Cabal into the base.
let's clarify. if Base is library for Cabal, then we should keep here
Cabal-specific things. if it's the library for users, then we should
make other decisions. i think that we need to have CabalLib, installed
with any haskell compiler, which should contain any features required
by Cabal. or even simpler, your compiler-independent code may be
included in Cabal itself and dead there without further changes

But for *people* we need upcoming versions of your module and this
requirement is very different from that is required for Cabal.
although just for this moment including FilePath into Base and using
it both by people and Cabal seems to be fine solution, in long term
this is just one more bomb for Haskell libs progress

> I realise you are trying to split up the base library, but Cabal
> requires it keep to be kept intact just a little bit longer ;)

i can't agree. all that Cabal requires is to import
compiler/os-specific functionality from preinstalled libs. but
preinstalled/=Base and moreover your functionality isn't *-specific


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