From: Brian H. <bri...@ql...> - 2003-02-24 19:41:50
|
Something just occurred to me. CVS has the ability to run a script on commits- explicitly, this is so you can run indent on code being committed. For those who don't know, indent is a program which (re-)indents C code. Allowing you to enforce convention like "no tabs", "curly braces on their own lines", etc. If something like this existed for Ocaml, we could use to force indenting rules (once they are settled on). Brian |
From: Maxence G. <max...@in...> - 2003-02-24 19:57:45
|
> Something just occurred to me. CVS has the ability to run a script on > commits- explicitly, this is so you can run indent on code being > committed. For those who don't know, indent is a program which > (re-)indents C code. Allowing you to enforce convention like "no tabs", > "curly braces on their own lines", etc. > > If something like this existed for Ocaml, we could use to force indenting > rules (once they are settled on). Camlp4 could be used for this, but it loses comments in phrases :-( If we want to put only comments between phrases, it could be what's needed. -- Maxence Guesdon |
From: Blair Z. <bl...@or...> - 2003-02-24 20:13:13
|
Brian Hurt wrote: > > Something just occurred to me. CVS has the ability to run a script on > commits- explicitly, this is so you can run indent on code being > committed. For those who don't know, indent is a program which > (re-)indents C code. Allowing you to enforce convention like "no tabs", > "curly braces on their own lines", etc. > > If something like this existed for Ocaml, we could use to force indenting > rules (once they are settled on). I think in general this is a bad idea. I would not want my code reindented upon commit. If there are commits that have poor coding style, then those could be pointed out by the other developers and fixed in subsequent commits. Also, this seems to mix style with real coding changes. Many times, I perform two separate commits to make code reviews easier, one for coding changes, and one for style changes. Best, Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: Brian H. <bri...@ql...> - 2003-02-24 20:29:09
|
On Mon, 24 Feb 2003, Blair Zajac wrote: > Brian Hurt wrote: > I think in general this is a bad idea. I would not want my code reindented > upon commit. I'm not that religous about indenting :-). And I've dealt with formatting diasters- including one file that had been editted by three different people, in three different editors, using both unix and windows style tabbing, different indent levels, and different tab stops. Which made me appreciate enforced standard indenting. > > Also, this seems to mix style with real coding changes. Many times, I > perform two separate commits to make code reviews easier, one for > coding changes, and one for style changes. > Yep. Nothing is more horrifying than seeing a log message that reads "fixed indenting, and a couple of bugs". Because you know that the reindenting touched almost every single line of code, making diffs nigh on to impossible, and hiding what the real changes are. Been there, done that too. Brian |
From: Chris H. <ch...@d6...> - 2003-02-24 20:56:46
|
Please don't let this go the way of most community projects and get bogged down in indentation style and other meta issues. Make some incredibly minimum directory layout suggestions and minimal project documentation (something like text file called "description.txt" in the root of each module). Then get a ton of code up there. Deal with the consequences later. The number of community projects with intricate and beautiful submission specifications and no useful code or users far outweighs the number of useful projects bogged down by bad indentation and planning. Chris |
From: Maxence G. <max...@in...> - 2003-02-24 21:39:50
|
> Make some incredibly minimum directory layout suggestions and minimal > project documentation (something like text file called "description.txt" in > the root of each module). Then get a ton of code up there. Deal with the > consequences later. The number of community projects with intricate and > beautiful submission specifications and no useful code or users far > outweighs the number of useful projects bogged down by bad indentation and > planning. I don't think uploading a ton of code and deal with consequences *later* is the easy way : someone will have to sort the functions, and try to give some consistency for the functions of a module. This can be very difficult when it means finding the good functions among hundreds. What about this other way : let's find some topics for modules (strings, lists, ...), then for each topic ask everyone what functions are missing and useful, then upload them or code them. Otherwise, I'm afraid the mess in the libraries will result in mess in programs using them. Building stable libraries will make them more usable : I don't think anyone would use a library whose interface is always changing. -- Maxence Guesdon1 |
From: Manos R. <er...@cs...> - 2003-02-25 02:51:02
|
On Mon, Feb 24, 2003 at 10:34:07PM +0100, Maxence Guesdon wrote: > > Make some incredibly minimum directory layout suggestions and minimal > > project documentation (something like text file called "description.txt" in > > the root of each module). Then get a ton of code up there. Deal with the > > consequences later. The number of community projects with intricate and > > beautiful submission specifications and no useful code or users far > > outweighs the number of useful projects bogged down by bad indentation and > > planning. > > I don't think uploading a ton of code and deal with consequences > *later* is the easy way : someone will have to sort the functions, and > try to give some consistency for the functions of a module. This can > be very difficult when it means finding the good functions among > hundreds. > > What about this other way : let's find some topics for modules > (strings, lists, ...), then for each topic ask everyone what functions > are missing and useful, then upload them or code them. Otherwise, I'm > afraid the mess in the libraries will result in mess in programs using > them. A lot of ideas for different projects have been going around. It seems different people are looking for a) a shadow of the standard library, with extensions, such as tail-recursive versions of all the List functions (where it's possible). b) a general repository of libraries, like the Humps, but including code in library form (as opposed to finished programs), and actually storing the code (as opposed to just pointing to it, as in the humps). c) An shared project to develop new libraries for Ocaml, as the need rises. It seems to me that the priority is the shadow of the standard library. For that, we already have a decomposition to follow, that of the standard library itself. We need a name, a license, a compilation strategy, and an installation strategy. For the name, somebody mentioned ExtLib. For the license, the argument has been made that we would be extending the standard library, and it would be much simpler to keep its license. The obvious choices for the latter two are OCamlMakefile and findlib. To proceed, I suppose we could all upload our proposals for extensions to the StdLib modules, and vote about the appropriateness of each one. (I have no experience with distributed development, so I have no idea about the actual workings of this, but the Boost's guidelines can serve a starting point.) -- Manos |
From: Nicolas C. <war...@fr...> - 2003-02-25 03:06:33
|
> It seems to me that the priority is the shadow of the standard library. > For that, we already have a decomposition to follow, that of the > standard library itself. We need a name, a license, a compilation > strategy, and an installation strategy True, I agree to concentrate first on ExtLib and then later discuss about the OCaml web librairies repository > For the name, somebody mentioned ExtLib. For the license, the argument > has been made that we would be extending the standard library, and it > would be much simpler to keep its license. The obvious choices for the > latter two are OCamlMakefile and findlib. I'm one of the few Windows OCaml users, and findlib nor OCamlMake aren't available on this platform. I wrote a tool sometime ago called "ocamake" which is doing I think the same as OCamlMake. It's a command line tool that take several ml / mli ( and others ) files = as input, call ocamldep and then compile the whole using ocamlc or ocamlopt.= It has also an option to generate a Makefile that can be used as input for either GNU Make or Microsoft NMAKE ( no more use of two separate Makefile and Makefile.nt ). I would of course be more than happy if the ExtLib community would like t= o use this tool as a standard. It has been roughly tested and the full OCam= l sourcefile is available at http://tech.motion-twin.com . BTW, it only us= e the Unix OCaml library and don't rely on any non standard library. Perhaps I could add an XML input that well enable it to load xml project descriptors =E0 la Ant. What do you think about it ? > To proceed, I suppose we could all upload our proposals for extensions = to > the StdLib modules, and vote about the appropriateness of each one. > (I have no experience with distributed development, so I have no idea > about the actual workings of this, but the Boost's guidelines can serve > a starting point.) Please read the proposal rules I've been writting in the "Goals & Process= " thread. Nicolas Cannasse |
From: fva <fv...@ts...> - 2003-02-25 09:27:15
|
Again voting on somebody else's proposals... Manos Renieris wrote: >On Mon, Feb 24, 2003 at 10:34:07PM +0100, Maxence Guesdon wrote: >It seems to me that the priority is the shadow of the standard library. > Agreed. >For that, we already have a decomposition to follow, that of the >standard library itself. We need a name, a license, a compilation >strategy, and an installation strategy. > >For the name, somebody mentioned ExtLib. > Agreed. >For the license, the argument >has been made that we would be extending the standard library, and it >would be much simpler to keep its license. > Agreed. >The obvious choices for the >latter two are OCamlMakefile and findlib. > Agreed for both (but taken note of the problems with people in Windows & their tools). Regards, Francisco Valverde |
From: John M. S. <sk...@oz...> - 2003-02-25 17:38:22
|
>> For that, we already have a decomposition to follow, that of the >> standard library itself. We need a name, a license, a compilation >> strategy, and an installation strategy. I think we should be careful here. In my opinion Boost went entirely off the rails by chosing a special make tool, and then modifying that so that to actually build boost became a total nightmare. They failed to follow my recommendation:-) I recommended Python script as the build tool, and they thought it was 'too heavy' which of course turned out to be a joke compared to having to download and build a custom tool -- which needed constant modification. I personally DESPISE make and friends, I think they're total garbage. While they automate some tasks nicely, trying to fool make into doing all the build/test/install tasks correctly requires considerably expertise and hackery. Python, on the other hand, is a full scale programming language. Well, we should probably use ocaml script instead :-) -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Manos R. <er...@cs...> - 2003-02-25 19:39:48
|
On Wed, Feb 26, 2003 at 04:38:15AM +1100, John Max Skaller wrote: > >>For that, we already have a decomposition to follow, that of the > >>standard library itself. We need a name, a license, a compilation > >>strategy, and an installation strategy. > > I think we should be careful here. Indeed. I actually now think that we should not rely on anything the ocaml core team does not rely on. Under unix, that means ocaml and make. If they don't need python to install the ocaml libraries, we don't need it for ExtLib either. So, my proposal would be like this: we create a `ocamlc -where`/extlib directory, with extlib.cm* files in it. To use extlib, you need to compile with +extlib extlib.cma. (Please forgive my unixisms; if something will not work under Windows, please free to suggest alternatives that will). Now, for the level of the library, what I see for the first phase is (I think) very close to Stefano's: We need things like String.of_char and List.rev_combine. It seems to me that the simplest way to get them is by writing .ml files like this string.ml: include String let of_char = String.make 1 and .mli files that replicate the string.mli from the stdlib and add the extensions of extlib. Then we just pack everything in extlib.cma. The ocaml team can decide to move things for stdlib to extlib (or the other way round) as they wish. > In my opinion Boost went entirely > off the rails by chosing a special make tool, and then modifying > that so that to actually build boost became a total nightmare. > > They failed to follow my recommendation:-) > > I recommended Python script as the build tool, and they > thought it was 'too heavy' which of course turned out > to be a joke compared to having to download and build > a custom tool -- which needed constant modification. > > I personally DESPISE make and friends, I think they're > total garbage. While they automate some tasks nicely, > trying to fool make into doing all the build/test/install > tasks correctly requires considerably expertise and hackery. > > Python, on the other hand, is a full scale programming language. > > Well, we should probably use ocaml script instead :-) > > -- > John Max Skaller, mailto:sk...@oz... |
From: Stefano Z. <za...@bo...> - 2003-02-26 10:12:39
|
On Tue, Feb 25, 2003 at 02:39:39PM -0500, Manos Renieris wrote: > Now, for the level of the library, what I see for the first > phase is (I think) very close to Stefano's: If you like I can sent you on the list (to which I'm _not_ subscribed) the set of functions I've collected that I would like to see in the ocaml standard library. Cheers. -- Stefano Zacchiroli - Undergraduate Student of CS @ Uni. Bologna, Italy zack@{cs.unibo.it,debian.org,bononia.it} - http://www.bononia.it/zack/ " I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! " -- G.Romney |
From: fva <fv...@ts...> - 2003-02-27 12:04:47
|
Stefano Zacchiroli wrote: >If you like I can sent you on the list (to which I'm _not_ subscribed) >the set of functions I've collected that I would like to see in the >ocaml standard library. > Yes of course... I think everybody would appreciate that. Regards, Fran Valverde |
From: Stefano Z. <za...@bo...> - 2003-02-27 13:52:36
|
On Wed, Feb 26, 2003 at 09:36:54PM -0500, Manos Renieris wrote: > That would help. Thanks. - val String.explode : string -> char list - val String.implode : char list -> string (* like perl's chomp function, remove trailing newline characters *) - val String.chomp : string -> string (* fold left on file lines (without trailing newline), I don't know in which module this functions should go, maybe Sys? *) - val fold_file : ('a -> string -> 'a) -> 'a -> string -> 'a (* iter on file lines *) - val iter_file : (string -> unit) -> string -> unit - val Dbm.fold_left - val Hashtbl.keys : ('a, 'b) Hashtbl.t -> 'a list - val Hashtbl.values : ('a, 'b) Hashtbl.t -> 'b list (* remove all bindings of a given keys *) - val Hashtbl.remove_all : ('a, 'b) Hashtbl.t -> 'a -> unit (* like Hashtbl.fold but working on ordered key list. Find a better name!, compare defaults to Pervasives.compare *) - val Hashtbl.sorted_fold: ?compare: ('a -> 'a -> int) -> ('a -> 'b -> 'c -> 'c) -> ('a, 'b) Hashtbl.t -> 'c -> 'c (* as above for iter *) - val Hashtbl.sorted_iter: ?compare: ('a -> 'a -> int) -> ('a -> 'b -> unit) -> ('a, 'b) Hashtbl.t -> unit (* return all bindings of a given key *) - val List.assoc_all: 'a -> ('a * 'b) list -> 'b list (* as above but use physical equality *) - val List.assq_all: 'a -> ('a * 'b) list -> 'b list - val Sys.copy: src:string -> dst:string -> unit (* add support for recursive directory creation for Unix.mkdir *) - support for "-p" to Unix.mkdir - Unix.is_directory : ?follow_sym_link: bool -> string -> bool - Unix.is_regular - Unix.is_symlink - ... (* predicates over filenames, optional argument defaults to false, if it is true predicate are over symlink target *) (* return size of a given file; maybe Sys.filesize? *) - Unix.filesize : string -> bool (* "/ls" command interface *) - Unix.ls : string -> string list - val Random.char: unit -> char - val Random.string: int -> char (* argument is string length *) (* predicate negation *) - val non: ('a -> bool) -> ('a -> bool) (* given a 'a option returns the 'a value if it's Some _ or raise an exception, find a better name! *) - val unsome : 'a option -> 'a Hope this helps, Cheers. -- Stefano Zacchiroli - Undergraduate Student of CS @ Uni. Bologna, Italy zack@{cs.unibo.it,debian.org,bononia.it} - http://www.bononia.it/zack/ " I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! " -- G.Romney |
From: Michal M. <mal...@pl...> - 2003-02-27 16:04:27
|
On Thu, Feb 27, 2003 at 02:51:58PM +0100, Stefano Zacchiroli wrote: > (* given a 'a option returns the 'a value if it's Some _ or raise an > exception, find a better name! *) > - val unsome : 'a option -> 'a Isn't this called valOf in SML? But unsome sounds better to me. -- : Michal Moskal ::::: malekith/at/pld-linux.org : GCS {C,UL}++++$ a? !tv : PLD Linux ::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h |
From: Eric C. C. <ec...@cm...> - 2003-02-27 19:02:50
|
On Thu, Feb 27, 2003 at 05:00:49PM +0100, Michal Moskal wrote: > On Thu, Feb 27, 2003 at 02:51:58PM +0100, Stefano Zacchiroli wrote: > > (* given a 'a option returns the 'a value if it's Some _ or raise an > > exception, find a better name! *) > > - val unsome : 'a option -> 'a > > Isn't this called valOf in SML? But unsome sounds better to me. This might not be to everyone's tastes, but I often use a related function that I call "the": val the : 'a option ref -> 'a which fails with Failure "uninitialized variable" when the (dereferenced) option is None. I typically use it with 'a option refs that represent global variables, like options set on the command line: let channel = open_in (the input_file) in ... etc. -- Eric C. Cooper e c c @ c m u . e d u |
From: Olivier A. <ol...@us...> - 2003-02-27 20:06:18
|
Eric C. Cooper [Thursday 27 February 2003] : > > On Thu, Feb 27, 2003 at 05:00:49PM +0100, Michal Moskal wrote: > > On Thu, Feb 27, 2003 at 02:51:58PM +0100, Stefano Zacchiroli wrote: > > > (* given a 'a option returns the 'a value if it's Some _ or raise an > > > exception, find a better name! *) > > > - val unsome : 'a option -> 'a > > > > Isn't this called valOf in SML? But unsome sounds better to me. > > This might not be to everyone's tastes, but I often use a related > function that I call "the": > val the : 'a option ref -> 'a > which fails with Failure "uninitialized variable" when the > (dereferenced) option is None. I use something like this too : ,----[ uref.ml ] | exception Uninitialised | type 'a uref = 'a option ref | let uref () = ref None | let (&=) r v = r := Some v | let is_init r = !r <> None | let (!!) r = | match !r with | | None -> raise Uninitialised | | Some v -> v `---- ,----[ uref.mli ] | exception Uninitialised | type 'a uref = 'a option ref | val uref : unit -> 'a uref | val ( &= ) : 'a uref -> 'a -> unit | val is_init : 'a uref -> bool | val ( !! ) : 'a uref -> 'a `---- -- Olivier |
From: Nicolas C. <war...@fr...> - 2003-02-28 02:45:30
|
> > > > (* given a 'a option returns the 'a value if it's Some _ or raise an > > > > exception, find a better name! *) > > > > - val unsome : 'a option -> 'a > > > > > > Isn't this called valOf in SML? But unsome sounds better to me. > > > > This might not be to everyone's tastes, but I often use a related > > function that I call "the": > > val the : 'a option ref -> 'a > > which fails with Failure "uninitialized variable" when the > > (dereferenced) option is None. > > I use something like this too : > I also have mine, but in a different way ( that's "named" globals - better debug & type abstraction ) But since I hasn't used it much, I was wondering if it should be part of the ExtLib, maybe ? exception Global_not_initialized of string module Global : sig type 'a t val empty : string -> 'a t (* returns an new named empty global *) val name : 'a t -> string (* retrieve the name of a global *) val set : 'a t -> 'a -> unit (* set the global value contents *) val get : 'a t -> 'a (* get the global value contents - raise Global_not_initialized if not defined *) val undef : 'a t -> unit (* reset the global value contents to undefined *) val isdef : 'a t -> bool (* tell if the global value has been set *) val opt : 'a t -> 'a option (* return None if the global is undefined, or Some v where v is the current global value contents *) end Nicolas Cannasse |
From: fva <fv...@ts...> - 2003-02-28 10:08:37
|
Nicolas Cannasse wrote: >I also have mine, but in a different way ( that's "named" globals - better >debug & type abstraction ) >But since I hasn't used it much, I was wondering if it should be part of the >ExtLib, maybe ? > > >exception Global_not_initialized of string > >module Global : > sig > > type 'a t > > val empty : string -> 'a t (* returns an new named empty global *) > val name : 'a t -> string (* retrieve the name of a global *) > val set : 'a t -> 'a -> unit (* set the global value contents *) > val get : 'a t -> 'a (* get the global value contents - raise >Global_not_initialized if not defined *) > val undef : 'a t -> unit (* reset the global value contents to undefined *) > val isdef : 'a t -> bool (* tell if the global value has been set *) > > val opt : 'a t -> 'a option (* return None if the global is undefined, or >Some v where v is the current global value contents *) > > end > I've also something similar for generating new names, etc... I think it worth putting in an extended lib. Regards, Fva |
From: Nicolas C. <war...@fr...> - 2003-02-28 03:39:04
|
> > That would help. Thanks. > > - val String.explode : string -> char list > - val String.implode : char list -> string Agree > (* like perl's chomp function, remove trailing newline characters *) > - val String.chomp : string -> string Uhm, why not, but this need some discuss on implementation since newline is "\r\n" under windows and "\n" under *nix.... > (* fold left on file lines (without trailing newline), I don't know in > which module this functions should go, maybe Sys? *) > - val fold_file : ('a -> string -> 'a) -> 'a -> string -> 'a > (* iter on file lines *) > - val iter_file : (string -> unit) -> string -> unit perhaps : val iter_in : (string -> unit) -> in_channel -> unit val map_in : (string -> 'a) -> in_channel -> 'a list val fold_in : ('a -> string -> 'a) -> 'a -> in_channel -> 'a are better so it can work on many kind of descriptors and does not have to handle the "file not found" problems I propose also : val read_lines : in_channel -> string list val read_all : in_channel -> string that returns all the contents ( up to End_of_file ) > - val Dbm.fold_left Uh, never used Dbm... > - val Hashtbl.keys : ('a, 'b) Hashtbl.t -> 'a list > - val Hashtbl.values : ('a, 'b) Hashtbl.t -> 'b list > (* remove all bindings of a given keys *) > - val Hashtbl.remove_all : ('a, 'b) Hashtbl.t -> 'a -> unit Agree > (* like Hashtbl.fold but working on ordered key list. Find a better > name!, compare defaults to Pervasives.compare *) > - val Hashtbl.sorted_fold: ?compare: ('a -> 'a -> int) -> ('a -> 'b -> 'c -> 'c) -> ('a, 'b) Hashtbl.t -> 'c -> 'c > (* as above for iter *) > - val Hashtbl.sorted_iter: ?compare: ('a -> 'a -> int) -> ('a -> 'b -> unit) -> ('a, 'b) Hashtbl.t -> unit Aren't theses strange and very particular ones ?? > (* return all bindings of a given key *) > - val List.assoc_all: 'a -> ('a * 'b) list -> 'b list > (* as above but use physical equality *) > - val List.assq_all: 'a -> ('a * 'b) list -> 'b list > - val Sys.copy: src:string -> dst:string -> unit > > (* add support for recursive directory creation for Unix.mkdir *) > - support for "-p" to Unix.mkdir > - Unix.is_directory : ?follow_sym_link: bool -> string -> bool > - Unix.is_regular > - Unix.is_symlink > - ... (* predicates over filenames, optional argument defaults to false, > if it is true predicate are over symlink target *) > (* return size of a given file; maybe Sys.filesize? *) > - Unix.filesize : string -> bool > (* "/ls" command interface *) > - Unix.ls : string -> string list All theses cannot be part of the ExtLib, since we're only focusing right now on the StdLib Extension ( and Unix is not part of the StdLib altought it's part of the standard distribution ) and also theses function need some C code to work. > - val Random.char: unit -> char > - val Random.stringi: int -> char (* argument is string length *) Don't like theses > (* predicate negation *) > - val non: ('a -> bool) -> ('a -> bool) Since there is some need for such basic functions, let's put that in a module Logic > (* given a 'a option returns the 'a value if it's Some _ or raise an > exception, find a better name! *) > - val unsome : 'a option -> 'a Global is much more complete Thanks, Nicolas Cannasse |
From: Olivier A. <ol...@us...> - 2003-02-28 08:57:44
|
> > (* given a 'a option returns the 'a value if it's Some _ or raise an > > exception, find a better name! *) > > - val unsome : 'a option -> 'a > > Global is much more complete Huh ?? that's not the same thing at all ... This kind of function is useful when dealing with optional arguments. There's more of this kind of fonctions (manipulating 'a option values) : let may f = function | None -> () | Some v -> f v let may_map f = function | None -> None | Some v -> Some (f v) let is = function | None -> false | Some _ -> true let default x = function | None -> x | Some v -> v -- Olivier |
From: Nicolas C. <war...@fr...> - 2003-02-28 10:24:23
|
> > > (* given a 'a option returns the 'a value if it's Some _ or raise an > > > exception, find a better name! *) > > > - val unsome : 'a option -> 'a > > > > Global is much more complete > > Huh ?? that's not the same thing at all ... This kind of function is > useful when dealing with optional arguments. > > There's more of this kind of fonctions (manipulating 'a option values) : > > let may f = function > | None -> () > | Some v -> f v > > let may_map f = function > | None -> None > | Some v -> Some (f v) > > let is = function > | None -> false > | Some _ -> true > > let default x = function > | None -> x > | Some v -> v Hum sorry :) It was in the same thread so I messed up... Theses are nices, but what package would they belong to ? Nicolas Cannasse |
From: Fernando A. <fer...@cc...> - 2003-02-28 15:14:36
|
> > let default x = function > > | None -> x > > | Some v -> v > > Hum sorry :) > It was in the same thread so I messed up... > Theses are nices, but what package would they belong to ? These functions extend the Pervasives module, so they belong under ExtLib (no sub-module) or maybe ExtLib.Pervasives (not sure about that) Fernando |
From: fva <fv...@ts...> - 2003-02-28 10:20:53
|
Nicolas Cannasse wrote: >>>That would help. Thanks. >>> >>> >>- val String.explode : string -> char list >>- val String.implode : char list -> string >> >> > >Agree > Agree. >> (* like perl's chomp function, remove trailing newline characters *) >>- val String.chomp : string -> string >> >> > >Uhm, why not, but this need some discuss on implementation since newline is >"\r\n" under windows and "\n" under *nix.... > Agree with the consideration for the this double character ending quirks & so. >> (* fold left on file lines (without trailing newline), I don't know in >> which module this functions should go, maybe Sys? *) >>- val fold_file : ('a -> string -> 'a) -> 'a -> string -> 'a >> (* iter on file lines *) >>- val iter_file : (string -> unit) -> string -> unit >> >> > >perhaps : > >val iter_in : (string -> unit) -> in_channel -> unit >val map_in : (string -> 'a) -> in_channel -> 'a list >val fold_in : ('a -> string -> 'a) -> 'a -> in_channel -> 'a > >are better so it can work on many kind of descriptors and does not have to >handle the "file not found" problems > >I propose also : > >val read_lines : in_channel -> string list >val read_all : in_channel -> string > I like better the "in_channel" typed functions. I also use iteri, fold and iter on directories filtering out "." and ".." for doing experiments on many files (based in Unix.opendir, closedir). Haven't looked if the stdlib opted them in for ages... BTW doesn't this look like a pattern on an abstract structure with sequential access? Wouldn't a single signature and a number of structure instantiations be in order here... Ease of use & all that... >that returns all the contents ( up to End_of_file ) > > > >>- val Dbm.fold_left >> >> > >Uh, never used Dbm... > Me neither. Can't judge. >>- val Hashtbl.keys : ('a, 'b) Hashtbl.t -> 'a list >>- val Hashtbl.values : ('a, 'b) Hashtbl.t -> 'b list >> (* remove all bindings of a given keys *) >>- val Hashtbl.remove_all : ('a, 'b) Hashtbl.t -> 'a -> unit >> >> > >Agree > Yes. I also miss those when I've been perling for some time... >> (* like Hashtbl.fold but working on ordered key list. Find a better >> name!, compare defaults to Pervasives.compare *) >>- val Hashtbl.sorted_fold: ?compare: ('a -> 'a -> int) -> ('a -> 'b -> >> >> >'c -> 'c) -> ('a, 'b) Hashtbl.t -> 'c -> 'c > >> (* as above for iter *) >>- val Hashtbl.sorted_iter: ?compare: ('a -> 'a -> int) -> ('a -> 'b -> >> >> >unit) -> ('a, 'b) Hashtbl.t -> unit > >Aren't theses strange and very particular ones ?? > I see the perlmania here as well, but they are worth, for me at least, in *very particular contexts* (text processing). >> (* return all bindings of a given key *) >>- val List.assoc_all: 'a -> ('a * 'b) list -> 'b list >> (* as above but use physical equality *) >>- val List.assq_all: 'a -> ('a * 'b) list -> 'b list >> Yes. I have these in the more general context of "maps". >>- val Sys.copy: src:string -> dst:string -> unit >> >> (* add support for recursive directory creation for Unix.mkdir *) >>- support for "-p" to Unix.mkdir >>- Unix.is_directory : ?follow_sym_link: bool -> string -> bool >>- Unix.is_regular >>- Unix.is_symlink >>- ... (* predicates over filenames, optional argument defaults to false, >> if it is true predicate are over symlink target *) >> (* return size of a given file; maybe Sys.filesize? *) >>- Unix.filesize : string -> bool >> (* "/ls" command interface *) >>- Unix.ls : string -> string list >> >> > >All theses cannot be part of the ExtLib, since we're only focusing right now >on the StdLib Extension ( and Unix is not part of the StdLib altought it's >part of the standard distribution ) and also theses function need some C >code to work. > So no using of Unix, uh? I see: standalone and all that. >>- val Random.char: unit -> char >>- val Random.stringi: int -> char (* argument is string length *) >> >> > >Don't like theses > Don't see the point either, really. >> (* predicate negation *) >>- val non: ('a -> bool) -> ('a -> bool) >> >> > >Since there is some need for such basic functions, let's put that in a >module Logic > Interesting. Agree. >> (* given a 'a option returns the 'a value if it's Some _ or raise an >> exception, find a better name! *) >>- val unsome : 'a option -> 'a >> >> > >Global is much more complete > Think so too. I liked the name "the" for this function, though. It also looks like the iota quantifier and perhaps should go into Logic? Regards, Fran Valverde |
From: Stefano Z. <za...@bo...> - 2003-02-28 13:16:09
|
On Fri, Feb 28, 2003 at 12:38:12PM +0900, Nicolas Cannasse wrote: > > (* like perl's chomp function, remove trailing newline characters *) > > - val String.chomp : string -> string > Uhm, why not, but this need some discuss on implementation since newline is > "\r\n" under windows and "\n" under *nix.... Yes, but I'm almost sure that somewhere this information is already available in the standard library. Think for example at the input_line function that read a line from an input channel without trailing "newline", on *nix it removes the trailing "\n" but I'm almost sure that under win it removes trailing "\r\n" and so on on mac. > perhaps : > val iter_in : (string -> unit) -> in_channel -> unit > val map_in : (string -> 'a) -> in_channel -> 'a list > val fold_in : ('a -> string -> 'a) -> 'a -> in_channel -> 'a > > are better so it can work on many kind of descriptors and does not have to > handle the "file not found" problems Agreed. > I propose also : > val read_lines : in_channel -> string list Better "input_lines" for coherence with Pervasives.input_line > val read_all : in_channel -> string Better "input_all", "read_*" prefixed functions in Pervasives act on stdin only and not on generic input channels. Therefore I also suggest "read_lines" which is a "input_lines" working on stdint and "read_all", the same for "input_all". Anyway is probably worthwhile to think at something like: val input_lines: ?inchan:in_channel -> string list val input_line: ?inchan:in_channel -> string with optional argument "inchan" defaulting to "stdin". This makes standard library more compact. > > - val Dbm.fold_left > Uh, never used Dbm... Ok, but trust me, a fold function is always useful! :-) > > - val Hashtbl.sorted_fold: ?compare: ('a -> 'a -> int) -> ('a -> 'b -> > > - val Hashtbl.sorted_iter: ?compare: ('a -> 'a -> int) -> ('a -> 'b -> > Aren't theses strange and very particular ones ?? Probably you are right, they are uncommon also in other standard libraries ... not really useful indeed. > All theses cannot be part of the ExtLib, since we're only focusing right now > on the StdLib Extension ( and Unix is not part of the StdLib altought it's > part of the standard distribution ) and also theses function need some C > code to work. Ok, we probably disagree on the idea of "standard library", I was thinking at it like "all the libraries that are part of the ocaml distribution". If you are looking only at Pervasives module remember that also Dbm isn't part of it ... > > - val Random.char: unit -> char > > - val Random.string: int -> char (* argument is string length *) > Don't like theses Why? > > - val non: ('a -> bool) -> ('a -> bool) > Since there is some need for such basic functions, let's put that in a > module Logic Is it worth the effort? Have you find many other functions for this module? > > - val unsome : 'a option -> 'a > Global is much more complete Uh? Cheers. -- Stefano Zacchiroli - Undergraduate Student of CS @ Uni. Bologna, Italy zack@{cs.unibo.it,debian.org,bononia.it} - http://www.bononia.it/zack/ " I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! " -- G.Romney |