Plan for file processing libs

[Bulat Ziganshin]

Hello Duncan,

Thursday, November 23, 2006, 4:51:39 PM, you wrote:

>> * NewBinary-like layer which provides binary I/O and serialization on
>>      top of Streams

> Actually, similarly, I don't think there is any need to tie a pure data
> structure modules like Data.ByteString (or the unicode variant
> Data.PackedString) to an IO package.

these are layers of *libraries*, not one super-library. it reflects
only functional dependencies of my own work and don't means that this
is the only plan possible. vice versa, as long as there are alternative
library designs, the functionality should be split into separate libs
in order to provide for alternative libraries ability to reuse existing code

just one example - as part of Streams library, i've developed
System.FD and System.MMapFile modules. these modules can't be used in
FPS, though, because my library by itself imports FPS in order to provide
ByteString I/O. so it seems that these modules should be put into
separate package, which may be imported both by FPS and Streams to
serve their needs

> If you're talking about standardising some kind of Binary module I'd
> much rather see one based on lazy byte strings since this is pure. There
> is no need to tie binary serialisation to IO, file handles, or your
> streams proposal.

> I know some people are working on such an implementation. I think it
> will be possibly to make a nice serialisation api that is both pure and
> high performance.

no, i don't speak about any standards, just about my understanding of
I/O library infrastructure which also includes Binary-alike as the
last layer. independent of this layer, I/O library needs a file API what
supports packed filenames for efficiency


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