Re: [Ocaml-lib-devel] Future of ExtLib

[Brian H. <bh...@sp...>]

On Fri, 19 Mar 2004, Nicolas Cannasse wrote:

> - base64 encode/decode
> - abstract high level I/O with support for C basic types ( read_i16 ,
> write_f16 ..... )
> - zlib deflate/inflate written in pure OCaml.

One of the things I've been nooddling around with is a radicaly new I/O 
arhitecture.  The basic idea is to make i/o more like java and less like 
C.  The core idea is that there would be four classes of objects:

1) sinks and sources.  These would be the fundamental sources/destinations 
of the data- files, sockets, and strings would all be sinks and/or 
sources.  Most likely these will be built on top of the old-style Ocaml 
I/O routines.

2) filters.  These look like a sink or source, but wrap either a 
sink/source or another filter.  Examples of filters would 
compression/decompression, encryption/decryption, mime or uu 
encode/decode, eoln conversion, etc.  Also, a filter might just collect 
statistics on the stuff as it goes by, not changing the data- so line 
counters, word counters, and check summers would be filters.

3) formatters and parsers.  Formatters take the fundamental datatypes of
ocaml (int, float, etc) and convert them into strings and write the
strings to a filter or source/sink.  Parsers take strings and parse them 
back into the fundamental types of ocaml.

4) Directories- collections of one or more sources or sinks or
subdirectories.  This is so we can deal with "multi-file" streams, like
tar or zip files.  This might also be a way to generically handle file 
system issues.  This might also be the way to deal with file forks on 
MacOS.

The questions I haven't answered yet are:

1) Unicode or no unicode?  It's not that converting to/from unicode into 
one of the utf- formats is so hard, it's just that now a stream of 
characters is a different concept than a stream of bytes, with different 
filters working on different types streams.  And a conversion object stuck 
in between.  All pipes would now be at least three objects deep 
(formatter, unicode conversion, source/sink), instead of just two.

2) What are the semantics of directories?  Do we want to include file 
system fun?

3) How to deal with the lack of polymorphism on formatters.  All of the 
implementations of this structure I've seen (ab)use polymorphism to 
implement the formatters- they have a print function which is overloaded 
for the specific types- print(int), print(float), etc.  Often they have an 
operator overloaded or defined as well.  I'd love to be able to have a 
print function with a signature filter -> 'a -> filter, but I can't think 
of how to do it.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian