Browse thread
[Caml-list] [ANN] The Missing Library
-
John Goerzen
-
Kenneth Knowles
- Alexander V. Voinov
-
John Goerzen
-
Maxence Guesdon
-
John Goerzen
- Maxence Guesdon
-
John Goerzen
-
Alain.Frisch@e...
-
John Goerzen
-
Alain.Frisch@e...
-
Nicolas Cannasse
-
Yamagata Yoriyuki
- Gerd Stolpmann
-
Nicolas Cannasse
-
Yamagata Yoriyuki
- Jacques GARRIGUE
- Nicolas Cannasse
-
Yamagata Yoriyuki
-
Yamagata Yoriyuki
-
Nicolas Cannasse
- oliver@f...
-
Alain.Frisch@e...
-
John Goerzen
- Henri DF
- Shawn Wagner
- james woodyatt
-
Alain.Frisch@e...
- Basile STARYNKEVITCH
-
John Goerzen
- Kenneth Knowles
- Florian Hars
-
Maxence Guesdon
- Eric C. Cooper
-
Kenneth Knowles
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-04-27 (15:46) |
From: | Yamagata Yoriyuki <yoriyuki@m...> |
Subject: | Re: [Caml-list] Re: Common IO structure |
From: "Nicolas Cannasse" <warplayer@free.fr> 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