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@gmail.com