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 RAA28971; Tue, 27 Apr 2004 17:46:04 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA29665 for ; Tue, 27 Apr 2004 17:46:03 +0200 (MET DST) Received: from smtp.mbg.ocn.ne.jp (mbg.ocn.ne.jp [210.190.142.181]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3RFk1jq029394 for ; Tue, 27 Apr 2004 17:46:01 +0200 Received: from localhost (p34096-adsau14honb7-acca.tokyo.ocn.ne.jp [220.111.84.96]) by smtp.mbg.ocn.ne.jp (Postfix) with ESMTP id 0B2AD5F2B; Wed, 28 Apr 2004 00:46:00 +0900 (JST) Date: Wed, 28 Apr 2004 00:43:58 +0900 (JST) Message-Id: <20040428.004358.45522587.yoriyuki@mbg.ocn.ne.jp> To: warplayer@free.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Common IO structure From: Yamagata Yoriyuki In-Reply-To: <016401c42bc4$b6438840$19b0e152@warp> References: <015701c42b9a$00065730$ef01a8c0@warp> <20040427.002643.78700697.yoriyuki@mbg.ocn.ne.jp> <016401c42bc4$b6438840$19b0e152@warp> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 yamagata:01 yoriyuki:01 yoriyuki:01 cannasse:01 warplayer:01 caml-list:01 2004:99 wrappers:01 developpers:01 extlib:01 camomile:01 ocamlnet:01 extlib:01 ocamlnet:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: "Nicolas Cannasse" Subject: Re: [Caml-list] Re: Common IO structure Date: Mon, 26 Apr 2004 21:28:53 +0200 > > 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. get/put are used in Camomie already, and input/output are used in ocamlnet. OO wrappers of Extlib IO are only recent addition, so changing Extlib is more natural. In this case, what Extlib should do is just changing OO wrappers. I do not think you need to change IO module itself. > > > 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). My philosophy is to make the type informative as far as possible. If some method does not work, I would rather remove the method, and notify this fact to a user in the compile time (not in the runtime). A user, or the library developer can provide wrappers if necessary. Philoshophy aside, I do not see how pos and available improve performance. pos certainly decreases performance. Anyways disks are much slower than CPU, so arguing small performance benefit is nonsense. Since there are many possible "improvements" (seek, unget, length, destination addresses), it would be better to stick the algebraically minimal specification. Note that I do not oppose extension as such. I oppose making them as the standard. > 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. Choosing a type of buffers is not trivial (except char, in this case I propose using stirng, of courst). For exmaple, what is for a Unicode channel? UTF8/UTF16/UTF32 strings, array, DynArray.t, all have their own advantage. And if someone uses UTF8, another uses UTF16 and so on, then there is not much point of having standard. Of course we would make "nread/nwrite" use a default buffer type (maybe list, as you do Extlib), but I doubt that such "filler" methods do any good. For extensibility, it is guaranteed when we agreed to use object. As I stated above, I do not oppose using extension of channel types. What I propose is just to make channels in each library an extension of "standard" channel objects, and to make standard channel work as an argument to the library API as far as possible. (or provide a converter) > > > 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. For characters, I have proposed bufferd IO. -- Yamagata Yoriyuki ------------------- 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