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 RAA07599; Thu, 29 Apr 2004 17:11:17 +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 RAA07671 for ; Thu, 29 Apr 2004 17:11:16 +0200 (MET DST) Received: from rabelais.socialtools.net (rabelais.socialtools.net [81.2.94.243]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3TFBFSH025991 for ; Thu, 29 Apr 2004 17:11:15 +0200 Received: by rabelais.socialtools.net (Postfix, from userid 108) id 481C4232DF; Thu, 29 Apr 2004 16:11:15 +0100 (BST) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id EC44C232DB; Thu, 29 Apr 2004 16:11:13 +0100 (BST) Message-ID: <40911AF6.7020105@socialtools.net> Date: Thu, 29 Apr 2004 16:10:46 +0100 From: Benjamin Geer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-gb, en, fr, it MIME-Version: 1.0 To: Richard Jones Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Common IO structure References: <016401c42bc4$b6438840$19b0e152@warp> <20040428.004358.45522587.yoriyuki@mbg.ocn.ne.jp> <016501c42c73$24e64b30$ef01a8c0@warp> <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> In-Reply-To: <20040429122305.GA6688@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on rabelais.socialtools.net X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Miltered: at concorde with ID 40911B13.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 apis:01 api:01 howto:01 api:01 tradeoff:01 buffering:01 buffering:01 encodings:01 encrypted:99 layered:01 abstraction:01 abstraction:01 decoding:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Richard Jones wrote: > Good user interface design does *not* require you to read manuals to > find out how to use it I don't expect programming APIs to be as obvious as user interfaces. If I can work out how to use an API without reading a tutorial or HOWTO, that's great, but if not, I don't see it as a flaw in the API. There is a tradeoff between power and flexibility on the one hand, and obviousness and simplicity on the other. > I deliberately chose to make > the common case this simple because it's the common case and people > shouldn't have to remember much to use it. Java does that, too. If your default encoding is UTF-8, and you want to read a UTF-8 file, you can write this instead: BufferedReader in = new BufferedReader(new FileReader(filename)); If you don't need buffering, you can write: FileReader in = new FileReader(filename); and read characters one at a time or in blocks, instead of line-by-line. I like the fact that the API makes a distinction between bytes and characters; I can deal with I/O as raw bytes, or I can use an optional layer that translates bytes into characters. If I don't need that layer, I don't have to pay for the overhead. Likewise, I can add buffering only if I need it. Best of all, if > Here's how you read in and parse a CSV file using my OCaml > CSV library: > > let csv = Csv.load csvfile in This seems to take too much for granted. How do I specify the encoding and the line endings? Is all that part of the Csv library, meaning that the Csv library has yet another mechanism for handling encodings? What if my file is encrypted or compressed? How do I make Csv.load use my decryption or decompression function? Do you see what I'm getting at? This is why I'm pleading for a layered API, so that character encoding, buffering, compression, encryption, and any other optional processing can be handled by optional layers that everyone can use, whether they're dealing with network protocols or just reading files from a disk. Moreover, I'm arguing that there should be some stream abstraction that can be passed around to things like Csv.load, and that different implementations of this abstraction should be free to implement decoding, decompression, and so on. Does that make sense to you? Ben ------------------- 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