From: Achim B. <bl...@la...> - 2004-01-20 12:39:45
|
Hello, Nicolas Cannasse wrote: > I sent this one a couple of weeks ago but didn't get any answer Probably because the module is not in CVS yet. You might be interested in a similar module I wrote for my ant system. www-mgi.informatik.rwth-aachen.de/~blume/pub/ant-current.tar.bz2 The file is ant/tools/IO.ml. Achim -- ________________________________________________________________________ | \_____/ | Achim Blumensath \O/ \___/\ | LaBRI / Bordeaux =o= \ /\ \| www-mgi.informatik.rwth-aachen.de/~blume /"\ o----| ____________________________________________________________________\___| |
From: Nicolas C. <war...@fr...> - 2004-01-21 16:29:17
|
> Hello, > > Nicolas Cannasse wrote: > > I sent this one a couple of weeks ago but didn't get any answer > > Probably because the module is not in CVS yet. I was actually waiting for people thoughs before putting it on the CVS. Does no-reply means that it's already perfect so I can add it ? :-) > You might be interested in a similar module I wrote for my ant system. > > www-mgi.informatik.rwth-aachen.de/~blume/pub/ant-current.tar.bz2 > > The file is ant/tools/IO.ml. I had a look at it but it's a different approach than my proposal. You're actually restricting the IO's to char/string IO while I'm proposing to have generics IO that can write/read anything ( chars and strings, but also tokens, lists, ... ). But the nice thing is to actually add the read/write_u16 , read/write_byte etc.... as you did in order to manipulate binary files easier. Nicolas Cannasse |
From: Yamagata Y. <yor...@mb...> - 2004-01-22 02:34:05
|
From: "Nicolas Cannasse" <war...@fr...> Subject: Re: [Ocaml-lib-devel] Re: Abstract IO Date: Wed, 21 Jan 2004 17:34:40 +0100 > I had a look at it but it's a different approach than my proposal. You're > actually restricting the IO's to char/string IO while I'm proposing to have > generics IO that can write/read anything ( chars and strings, but also > tokens, lists, ... ). Ok, I had a quick look. I think, 1) Output channels lack flush operation. Is that ok? 2) There would be pros and cons, but maybe objects (not abstract types) are more fitted to channels. It makes extension easier, for example. 3) I'd like to see filter type. (Btw, If you attachs sources as Text/Plain, not Application/Octetstream, then it makes viewing more easier.) -- Yamagata Yoriyuki |
From: Nicolas C. <war...@fr...> - 2004-01-24 08:51:10
|
> > I had a look at it but it's a different approach than my proposal. You're > > actually restricting the IO's to char/string IO while I'm proposing to have > > generics IO that can write/read anything ( chars and strings, but also > > tokens, lists, ... ). > > Ok, I had a quick look. I think, > > 1) Output channels lack flush operation. Is that ok? True, > 2) There would be pros and cons, but maybe objects (not abstract > types) are more fitted to channels. It makes extension easier, for > example. I don't see how it makes extension easier. Rewriting the basic functions inside an object or passing them to IO.create_in/out is slighty the same, except that object method lookup is more expensive. But I'm not against adding an OO wrapper to the IO module for people who prefers using objects. > 3) I'd like to see filter type. Can you explain more ? I thing that it would be nice to add something like a pipe : IO.pipe : () -> ('a,'b) input * ('a,'b,unit) output > (Btw, If you attachs sources as Text/Plain, not > Application/Octetstream, then it makes viewing more easier.) Here's a copy/paste of IO.mli , since some people are reading directly from the archives it's maybe better since attachments are discarded. I wanted to commit but looks like I can't checkout the CVS in developper mode (only anonymous). I'll try later. Best Regards, Nicolas Cannasse ----------- IO.mli -------------------- type ('a, 'b) input type ('a, 'b, 'c) output exception No_more_input exception Input_closed exception Output_closed val default_available : unit -> 'a option val default_close : unit -> unit val create_in : read:(unit -> 'a) -> nread:(int -> 'b) -> available:(unit -> int option) -> close:(unit -> unit) -> ('a, 'b) input val create_out : write:('a -> unit) -> nwrite:('b -> unit) -> flush:(unit -> unit) -> close:(unit -> 'c) -> ('a, 'b, 'c) output val read : ('a, 'b) input -> 'a val nread : ('a, 'b) input -> int -> 'b val available : ('a, 'b) input -> int option val close_in : ('a, 'b) input -> unit val write : ('a, 'b, 'c) output -> 'a -> unit val nwrite : ('a, 'b, 'c) output -> 'b -> unit val printf : ('a, string, 'b) output -> ('c, unit, string, unit) format4 -> 'c val flush : ('a, 'b, 'c) output -> unit val close_out : ('a, 'b, 'c) output -> 'c val input_string : string -> (char, string) input val output_string : unit -> (char, string, string) output val input_channel : in_channel -> (char, string) input val output_channel : out_channel -> (char, string, unit) output val input_enum : 'a Enum.t -> ('a, 'a Enum.t) input val output_enum : unit -> ('a, 'a Enum.t, 'a Enum.t) output |
From: Yamagata Y. <yor...@mb...> - 2004-01-24 23:01:15
|
From: "Nicolas Cannasse" <war...@fr...> Subject: Re: [Ocaml-lib-devel] Re: Abstract IO Date: Sat, 24 Jan 2004 09:55:54 +0100 > > 2) There would be pros and cons, but maybe objects (not abstract > > types) are more fitted to channels. It makes extension easier, for > > example. > > I don't see how it makes extension easier. Subtyping makes it possible that a channel has its own interface, and still behaves as a basic channel type. Of course, there is a cost of more complex typing. cryptokit(http://pauillac.inria.fr/~xleroy/software.html) and ocamlnet(http://ocamlnet.sourceforge.net/) make use of OO-channels. > > 3) I'd like to see filter type. > > Can you explain more ? I'm thinking of an interface like val apply_in : ('a, 'b) input -> ('a, 'b, 'c, 'd) filter -> ('c, 'd) input val apply_out : ('a, 'b, 'c, 'd) filter -> ('c, 'd, 'x) output -> ('a, 'b, 'x) output > I thing that it would be nice to add something like a pipe : > > IO.pipe : () -> ('a,'b) input * ('a,'b,unit) output Unless it launchs new threads each time, (or we implement continuation in ocaml) this has not much use. We have to track which inputs connect which outputs, oterwise the execution is blocked by the lack of incoming data. |
From: Achim B. <bl...@la...> - 2004-01-26 09:46:51
|
On Sat, Jan 24, 2004 at 09:55:54AM +0100, Nicolas Cannasse wrote: > Here's a copy/paste of IO.mli Just two comments. > exception No_more_input Why not just End_of_file? > val read : ('a, 'b) input -> 'a > val nread : ('a, 'b) input -> int -> 'b > val available : ('a, 'b) input -> int option > val close_in : ('a, 'b) input -> unit What about val seek : ('a, 'b) input -> int -> unit; val pos : ('a, 'b) input -> int; or, rather, define two input types: a sequential one and one with random access. Achim --=20 ________________________________________________________________________ | \_____/ | Achim Blumensath \O/ \___/\ | LaBRI / Bordeaux =3Do=3D \ /\ = \| www-mgi.informatik.rwth-aachen.de/~blume /"\ o----| ____________________________________________________________________\___| |
From: Nicolas C. <war...@fr...> - 2004-01-26 12:12:33
|
> Note that I suggested seek only for input streams. > > If I understand the interface correctly an object of type ('a, 'b) input > semantically corresponds to a list of objects of type 'a with one > selected position (the current one). Therefore, the semantics of seek > and pos should be: > > If "in" corresponds to the list a_0,...,a_n and a_i is the currently > selected element, then "pos in" should return i and "seek in k" should > mark a_k as new selected element. The only problem I see is that doesn't scale well with strings. As I show you before, you might consider strings as N-char-lists, but the semantics of reading depends for example if the file is open in binary of text mode. Other case : if you have a file containing N strings of X characters separated by \0 , then reading 3 strings will give you a position of 3*(X+1) - including the \0 separator. It's difficult to add a concept of "length" and "pos" on such tokens , although it's very easy to do in the case ('a,'a list) input. Regards, Nicolas Cannasse |
From: Nicolas C. <war...@fr...> - 2004-01-26 12:50:25
|
[...] > > Other case : if you have a file containing N strings of X characters > > separated by \0 , then reading 3 strings will give you a position of > > 3*(X+1) - including the \0 separator. It's difficult to add a concept of > > "length" and "pos" on such tokens , although it's very easy to do in the > > case ('a,'a list) input. > > So in this example you have an object of type > (string, string list) input. Physically, the different strings are > stored in a file separated by \0. But for the abstract interface this > is irrelevant. In your example, if you read 3 strings then pos should > return 3, /not/ the sum of the lengths of the individual strings, and if > you do a "seek in 14" then the implementation should go to the start > of the 15th string in the file. I agree with that, this is the correct behavior for a (string,string list) input, but what about a (char,string) input ? pos/seek should be expressed in the smallest unit of the two parameters ( char ). And here it's getting confusing because the \0 string separator is also a char. Nicolas Cannasse |
From: Achim B. <bl...@la...> - 2004-01-27 12:30:00
Attachments:
io.mli
|
On Mon, Jan 26, 2004 at 01:55:49PM +0100, Nicolas Cannasse wrote: > I agree with that, this is the correct behavior for a (string,string list) > input, but what about a (char,string) input ? pos/seek should be expressed > in the smallest unit of the two parameters ( char ). And here it's getting > confusing because the \0 string separator is also a char. What about the following definition: After a "seek inp n" inp is in the same state as if after its creation exactly n read operations where performed. I have attached my proposal for an interface including seek. Achim -- ________________________________________________________________________ | \_____/ | Achim Blumensath \O/ \___/\ | LaBRI / Bordeaux =o= \ /\ \| www-mgi.informatik.rwth-aachen.de/~blume /"\ o----| ____________________________________________________________________\___| |