From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA30219; Thu, 29 Apr 2004 17:58:27 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA28854 for ; Thu, 29 Apr 2004 17:58:26 +0200 (MET DST) Received: from aomori.annexia.org (annexia.force9.co.uk [212.56.101.183]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3TFwPSH000900 for ; Thu, 29 Apr 2004 17:58:25 +0200 Received: from rich by aomori.annexia.org with local (Exim 3.36 #1 (Debian)) id 1BJDvd-0003Eo-00 for ; Thu, 29 Apr 2004 16:58:25 +0100 Date: Thu, 29 Apr 2004 16:58:25 +0100 Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Common IO structure Message-ID: <20040429155825.GA10975@redhat.com> References: <20040428.015800.126758722.yoriyuki@mbg.ocn.ne.jp> <408EEE3E.7050008@socialtools.net> <20040428034415.GB19564@complete.org> <40902265.9040702@socialtools.net> <20040428214442.GE10198@excelhustler.com> <4090E597.1080603@socialtools.net> <20040429122305.GA6688@redhat.com> <40911AF6.7020105@socialtools.net> <20040429153538.GA14089@excelhustler.com> <40912369.6010301@socialtools.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40912369.6010301@socialtools.net> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Richard Jones X-Miltered: at concorde with ID 40912621.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 compressor:99 api:01 api:01 fuzzy:01 ltd:98 unicode:01 unicode:01 ocaml:01 caml:01 underlying:01 encoded:02 bytes:02 bytes:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, Apr 29, 2004 at 04:46:49PM +0100, Benjamin Geer wrote: > The key for me is that I need to be able to chain processing steps > together, so that I can, for example, decompress gzip format and convert > the result to Unicode, a few bytes at a time. This suggests to me that > the gzip compressor and the Unicode processor should themselves be > implementations of the standard File object, so I can wrap a gzip > decompressor around an underlying data source, then wrap the Unicode > decoder around the gzip decompressor. The advantage of this approach is > that the Unicode decoder doesn't know it's dealing with a gzip > decompressor; it only knows it's dealing with something it can read > bytes from. I can then easily remove the decompression step if needed. I entirely agree that this is needed. My focus however was on making it simple to do the common things, and possible to do the rare, hard stuff. So the API designer should start by writing example programs in the non-existant API. Here are some rather fuzzy ideas of mine: open IO (* Read a whole file. *) let content = slurp filename;; (* Get a list of lines from a compressed file. *) let lines = open filename >> unzip >> slurp_lines;; (* Call function f line-by-line on a UTF-16 encoded file. *) open filename >> utf16_decode >> slurp_lines >> (List.iter f);; There are some obvious problems (eg. how are files closed? is '>>' a reserved operator already?) but it's nice to think about what an easy to use API might look like first *before* thinking about the implementation. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment Learning Objective CAML for C, C++, Perl and Java programmers: http://www.merjis.com/richj/computers/ocaml/tutorial/ ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners