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 VAA15261; Mon, 26 Apr 2004 21:31:11 +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 VAA15132 for ; Mon, 26 Apr 2004 21:31:10 +0200 (MET DST) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3QJV9YM006331 for ; Mon, 26 Apr 2004 21:31:09 +0200 Received: from warp (chateaudeau-4-82-225-176-25.fbx.proxad.net [82.225.176.25]) by postfix3-1.free.fr (Postfix) with SMTP id 2DC35C4965; Mon, 26 Apr 2004 21:31:08 +0200 (CEST) Message-ID: <016401c42bc4$b6438840$19b0e152@warp> From: "Nicolas Cannasse" To: "Yamagata Yoriyuki" Cc: References: <00cb01c42afd$7fc1b430$19b0e152@warp><20040426.221606.71081508.yoriyuki@mbg.ocn.ne.jp><015701c42b9a$00065730$ef01a8c0@warp> <20040427.002643.78700697.yoriyuki@mbg.ocn.ne.jp> Subject: Re: [Caml-list] Re: Common IO structure Date: Mon, 26 Apr 2004 21:28:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; cannasse:01 warplayer:01 caml-list:01 wrappers:01 developpers:01 extlib:01 camomile:01 ocamlnet:01 extlib:01 behave:01 char:01 char:01 additionnal:01 zlib:01 buffering:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > You miss my point. What I propose is having agreement over I/O > channels. So, having OO wrappers only solves the half of our > problems. Another half is whether or not developpers accept > them. > > And from my point of view, your proposal has some problems. For one > thing, it is not compatible to the already existing I/O channels in > other libraries than Extlib. Camomile uses get and put for your read > and write, and ocamlnet and cryptokit uses input and output (IIRC) for > your nread and nwrite. So ? That's exactly what we're talking about it there : making a choice. And that include naming of course. I don't say that the name we choosed for ExtLib IO are better, it's just that "reading" and "writing" on an IO seems natural to me. > Another problem is that it is not minimal > enough. For character converters, it is impossible to predict how > many characters will be available, for example. And requiring "pos", > "nread", "nwrite" seems arbitrary for me. They are somtimes useful > and improvement, but not necessary. That's true, I agree with you but on the last point : they are necessary in order to get good performances. Concerning "available", it returns None if no data available. "pos" might throw an exception as well when unavailable (looks like pos and available should have same behavior here). And nread/nwrite can simply call n times read/write. That means that any library can put default implementation for additional "not minimal" constructs : they will behave poorly (writing a string char by char) but will interface well with other IO that are supporting them correctly. If implementing efficently nread/nwrite require additionnal effort, then let's implement a default behavior and implement it better later. Having theses functions make room for future improvements, which is not done with minimal IO. > Since I want that these interfaces are accepted as the common > standard, I wanted that the requirement is absolutely minimal. My > proposal in the previous mail is inspired by the view that channels > are co-inductive types defined by its constructer and consumer. > Without those methods, they are not channels any more. > > I'm interested in your opinion. Mapping several IO ( a zlib compression + a base64 encoding + a unicode reader ) and using them all together to read and write chars will definitly slow down. Buffering is our friend, and require some more constructs. Best Regards, Nicolas Cannasse ------------------- 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