You can subscribe to this list here.
2003 
_{Jan}

_{Feb}
(81) 
_{Mar}
(97) 
_{Apr}
(88) 
_{May}
(80) 
_{Jun}
(170) 
_{Jul}
(9) 
_{Aug}

_{Sep}
(18) 
_{Oct}
(58) 
_{Nov}
(19) 
_{Dec}
(7) 

2004 
_{Jan}
(22) 
_{Feb}
(9) 
_{Mar}
(28) 
_{Apr}
(164) 
_{May}
(186) 
_{Jun}
(101) 
_{Jul}
(143) 
_{Aug}
(387) 
_{Sep}
(69) 
_{Oct}
(14) 
_{Nov}
(8) 
_{Dec}
(99) 
2005 
_{Jan}
(10) 
_{Feb}
(34) 
_{Mar}
(24) 
_{Apr}
(7) 
_{May}
(41) 
_{Jun}
(20) 
_{Jul}
(3) 
_{Aug}
(23) 
_{Sep}
(2) 
_{Oct}
(26) 
_{Nov}
(41) 
_{Dec}
(7) 
2006 
_{Jan}
(6) 
_{Feb}
(3) 
_{Mar}
(11) 
_{Apr}

_{May}

_{Jun}
(5) 
_{Jul}
(8) 
_{Aug}
(20) 
_{Sep}

_{Oct}
(6) 
_{Nov}
(5) 
_{Dec}

2007 
_{Jan}

_{Feb}
(1) 
_{Mar}

_{Apr}
(3) 
_{May}
(2) 
_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}
(7) 
_{Oct}
(6) 
_{Nov}
(19) 
_{Dec}
(11) 
2008 
_{Jan}

_{Feb}
(7) 
_{Mar}
(9) 
_{Apr}
(21) 
_{May}
(42) 
_{Jun}
(27) 
_{Jul}
(28) 
_{Aug}
(26) 
_{Sep}
(16) 
_{Oct}
(32) 
_{Nov}
(49) 
_{Dec}
(65) 
2009 
_{Jan}
(35) 
_{Feb}
(20) 
_{Mar}
(36) 
_{Apr}
(42) 
_{May}
(111) 
_{Jun}
(99) 
_{Jul}
(70) 
_{Aug}
(25) 
_{Sep}
(15) 
_{Oct}
(29) 
_{Nov}
(3) 
_{Dec}
(18) 
2010 
_{Jan}
(10) 
_{Feb}
(4) 
_{Mar}
(57) 
_{Apr}
(63) 
_{May}
(71) 
_{Jun}
(64) 
_{Jul}
(30) 
_{Aug}
(49) 
_{Sep}
(11) 
_{Oct}
(4) 
_{Nov}
(2) 
_{Dec}
(3) 
2011 
_{Jan}
(1) 
_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}
(2) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}
(1) 
2012 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2013 
_{Jan}

_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(2) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24
(10) 
25
(23) 
26
(14) 
27
(14) 
28
(20) 

From: Michal Moskal <malekith@pl...>  20030226 17:16:41

On Wed, Feb 26, 2003 at 11:38:47AM 0500, Eric C. Cooper wrote: > (* Invoke (f ()) n times, for side effects. *) > > val repeat : int > (unit > unit) > unit > > (* Apply f to 0 .. n1, for side effects. *) > > val dotimes : int > (int > unit) > unit I belive for loop is more readable: repeat 20 f == for i = 1 to 20 do f () done dotimes 20 f == for i = 0 to 19 do f i done and gives more possiblities. Don't have strong opinions about other stuff here.  : Michal Moskal ::::: malekith/at/pldlinux.org : GCS {C,UL}++++$ a? !tv : PLD Linux ::::::: Wroclaw University, CS Dept : {E,w} {b++,e}>+++ h 
From: Michal Moskal <malekith@pl...>  20030226 17:16:33

On Wed, Feb 26, 2003 at 06:07:20PM +0100, fva wrote: > 1) If your submission was intended as a candidate module, I guess that > it should come along with at least documentation for the signature > primitives... I guess this was the idea. In fact I figured out sementics of all functions in a minute or two, I just wonder about complexities.  : Michal Moskal ::::: malekith/at/pldlinux.org : GCS {C,UL}++++$ a? !tv : PLD Linux ::::::: Wroclaw University, CS Dept : {E,w} {b++,e}>+++ h 
From: Luc Mazardo <Luc.M<azardo@cv...>  20030226 17:01:08

Perhaps it's a dummy question but why List.create doesn't exist ? module AdvancedList = struct let create n v = let rec create_aux l n v = match n with  0 > l  _ > (create_aux (v::l) (n1) v) in create_aux [] n v;; let rec create_with_fun f n = match n with  0 > []  _ > f() :: (create_with_fun f (n  1));; end  Luc.Mazardo@... 
From: fva <fva@ts...>  20030226 17:00:55

Nicolas Cannasse wrote: >Hi extlist, > >Here's my mutable list interface. >Implementation is available and mostly use the standard List library >function. > So this is a candidate for a new module for the extlib, *not* an extension for a particular lib in StdLib? >Mutable lists with in place modifications are very usable each time you were >previously using "list ref" > >I'm not putting any documentation with the interface, since every not >obvious function can be considered as to be removed or changed. >It also provide a set of functions based on item index in the list ( i'm >using this, but i'm not really sure it should be in the ExtLib MList... or >perhaps in an inner module ) > >I'm waiting for your comments. > I will try to be constructive and please do not be fooled by typed language... It is very difficult to convey constructive criticism: 1) If your submission was intended as a candidate module, I guess that it should come along with at least documentation for the signature primitives... This is the minimal documentation to show people how to use your module... (I know it's a pain in the neck... I'm only concerned that nobody would take the trouble of using it. Even though it's in the *supermagnificent* :) extlib. 2) If it was intended as an implementation for lists but with mutable characteristics... a) Why not make the connection more evident in the code? b) Why didn't you characterize the complexity of the functions (I guess this is what Moskal did with the questions he put to you) If the answer to both question is "because it was just an example", may I suggest that we *encourage* people submitting either: a) signatures: to state the purpose & conventions of the functions (preferrably in Ocamldoc, but *any* documentation would feel OK with me) b) or implementations: to be articulate as to the running complexities expected of the implementations in either of two ways: a) this function runs in O(whatever)... b) I haven't worked our or tested the complexity... Because I think this would improve *any* code's usability *enormously*. This could be done incrementally and cooperatively with users & such afterwards, but the original author should submit as much information as he is able about the "creature". Regards, Fran Valverde PS: On the technical aspect, yes, I would also try to mimic Stdlib' s way of using exceptions (like very few and overloaded so as to ease their percolation to the main library). F. > >Nicolas Cannasse > > > >exception Invalid_index of int >exception No_such_element > >module MList : > sig > type 'a t > > val empty : unit > 'a t > val isempty : 'a t > bool > > val copy : 'a t > 'a t > unit > val copy_list : 'a t > 'a list > unit > val from_list : 'a list > 'a t > val to_list : 'a t > 'a list > > val add : 'a t > 'a > unit > val push : 'a t > 'a > unit > val pop : 'a t > 'a (* raise No_such_element *) > val last : 'a t > 'a (* raise No_such_element *) > val first : 'a t > 'a (* raise No_such_element *) > val npop : 'a t > int > 'a list (* raise No_such_element *) > val clear : 'a t > unit > val length : 'a t > int > val add_sort : ('a > 'a > int) > 'a t > 'a > unit > > val hd : 'a t > 'a (* raise No_such_element *) > val tl : 'a t > 'a list (* raise No_such_element *) > val iter : ('a > unit) > 'a t > unit > val find : ('a > bool) > 'a t > 'a > val find_ex : ('a > bool) > 'a t > exn > 'a > val exists : ('a > bool) > 'a t > bool > val map : ('a > 'b) > 'a t > 'b list > val sort : ('a > 'a > int) > 'a t > unit > val filter : ('a > bool) > 'a t > unit > > val shuffle : 'a t > unit > > val remove : 'a t > 'a > unit (* only one element removed, tested with >( = ), raise Not_found *) > val remove_if : ('a > bool) > 'a t > unit > >(* indexes functions *) > > val index_of : 'a t > 'a > int (* raise Not_found *) > val at_index : 'a t > int > 'a (* raise Invalid_index *) > val index_of_with : ('a > bool) > 'a t > int (* raise Not_found *) > > val set : 'a t > int > 'a > unit (* raise Invalid_index *) > val remove_at_index : 'a t > int > unit (* raise Invalid_index *) > >end > > 
From: Eric C. Cooper <ecc@cm...>  20030226 16:39:02

Here are the functions (primarily extensions to List and String) that I find myself reusing. The settheoretic and combinatoric ones are probably too simplistic for general use, but I'll throw them out there for discussion.  Eric C. Cooper e c c @ c m u . e d u  (* * Additions to the List module. *) (* Generate the range of integers [a; a+1; ...; b] *) val range : int * int > int list (* List equivalent of Array.init *) val listi : int > (int > 'a) > 'a list (* List equivalent of Array.mapi *) val mapi : (int > 'a > 'b) > 'a list > 'b list (* List equivalent of Array.iteri *) val iteri : (int > 'a > unit) > 'a list > unit (* Reverse assoc *) (* can also add rassq, mem_rassoc/rassq, remove_rassoc/rassq if needed *) val rassoc : 'b > ('a * 'b) list > 'a (* Tailrecursively compute rev (map f list1) @ list2 *) val rev_map_append : ('a > 'b) > 'a list > 'b list > 'b list (* Split [x1; x2; ...; xN] into [x1; ...; x{n}] and [x{n+1}; ...; xN] *) val split_nth : int > 'a list > 'a list * 'a list (* Tailrecursively split [x1; x2; ...; xN] into [x{n}; ...; x1] and [x{n+1}; ...; xN] *) val rev_split_nth : int > 'a list > 'a list * 'a list (* Return the last element of a list. *) val last : 'a list > 'a (* Insert x at position n in list. Position 0 places x at the front; position (length list) places x at the end. *) val insert : 'a > int > 'a list > 'a list (* Remove first occurrence of x, if any, from list. *) val remove_first : 'a > 'a list > 'a list (* Remove all occurrences of x from list. *) val remove : 'a > 'a list > 'a list (* Remove a subset of elements from a list. *) val remove_subset : 'a list > 'a list > 'a list (* Rotate each element of a list to the left, so that the head becomes the last element. *) val rotate_left : 'a list > 'a list (* Homogeneous version of List.fold_left. Uses the head of the list as the initial value. *) val fold : ('a > 'a > 'a) > 'a list > 'a (* Test whether the first list is a subset of the second. *) val subset : 'a list > 'a list > bool (* Return cartesian product of two lists. *) val product : 'a list > 'b list > ('a * 'b) list (* Return all sublists of a list. *) val subsets : 'a list > 'a list list (* Return all nelement sublists of a list. *) val choose : int > 'a list > 'a list list (* Return all sublists with up to n elements. *) val choose_up_to : int > 'a list > 'a list list (* Remove duplicates from a sorted list, using a sortstyle comparison function that returns 0 for equality. *) val uniq : ('a > 'a > int) > 'a list > 'a list (* * Additions to the String module. *) (* String equivalents of Array.fold_left and Array.fold_right *) val string_fold_left : ('a > char > 'a) > 'a > string > 'a val string_fold_right : (char > 'a > 'a) > 'a > string > 'a (* Convert between strings and lists of chars. *) val explode : string > char list val implode : char list > string (* Convert between strings and lists of ints in the range 0 .. 255 *) val explode_bytes : string > int list val implode_bytes : int list > string (* Like [index_from] but searches at most [len] chars. *) (* can also add bounded_rindex if needed *) val bounded_index : string > pos:int > len:int > char > int (* * Miscellaneous control structures. *) (* Compute f (g x) *) (* It would be nice to have a standard infix operator for this. *) val compose : ('b > 'c) > ('a > 'b) > 'a > 'c (* Compute f^n x *) val iterate : ('a > 'a) > int > 'a > 'a (* Invoke (f ()) n times, for side effects. *) val repeat : int > (unit > unit) > unit (* Apply f to 0 .. n1, for side effects. *) val dotimes : int > (int > unit) > unit 
From: Eric C. Cooper <ecc@cm...>  20030226 15:36:05

On Wed, Feb 26, 2003 at 11:09:54AM +0100, Michal Moskal wrote: > Ordering of arguments is copy dst src? I thought copy src dst, but... > > > val copy_list : 'a t > 'a list > unit > > ...this made me think right. > > Maybe assign instead of copy would be better? It suggests the right > ordering of arguments. And I know each function here takes argument it > operates as first argument, so this shouldn't be hard to remember. This is a good case for copy ~src: x ~dst: y (remembering strcpy, bcopy, memcpy, ... in C)  Eric C. Cooper e c c @ c m u . e d u 
From: Michal Moskal <malekith@pl...>  20030226 10:13:32

On Wed, Feb 26, 2003 at 11:01:04AM +0900, Nicolas Cannasse wrote: > exception Invalid_index of int > exception No_such_element Maybe Invalid_argument "..." or Failure "..." would be better for both? IMHO this is more in style of existing ocaml std library. > module MList : > sig > type 'a t > > val empty : unit > 'a t > val isempty : 'a t > bool > > val copy : 'a t > 'a t > unit Ordering of arguments is copy dst src? I thought copy src dst, but... > val copy_list : 'a t > 'a list > unit ...this made me think right. Maybe assign instead of copy would be better? It suggests the right ordering of arguments. And I know each function here takes argument it operates as first argument, so this shouldn't be hard to remember. And one more Q : is copy constant time operation? > val from_list : 'a list > 'a t > val to_list : 'a t > 'a list > > val add : 'a t > 'a > unit At front or at end? I belive both versions should be available (i.e. list should be cyclic), since it doesn't give much overhead and gives more possiblities. If only pop/push are supported, why not use Stack module from std library? > val push : 'a t > 'a > unit > val pop : 'a t > 'a (* raise No_such_element *) > val last : 'a t > 'a (* raise No_such_element *) > val first : 'a t > 'a (* raise No_such_element *) > val npop : 'a t > int > 'a list (* raise No_such_element *) > val clear : 'a t > unit > val length : 'a t > int Is this constant time operation? > val add_sort : ('a > 'a > int) > 'a t > 'a > unit > > val hd : 'a t > 'a (* raise No_such_element *) > val tl : 'a t > 'a list (* raise No_such_element *) If other internal representation then 'a list is used this will have to be O(n) operation, so I doubt it's good idea to provide it. > val iter : ('a > unit) > 'a t > unit > val find : ('a > bool) > 'a t > 'a > val find_ex : ('a > bool) > 'a t > exn > 'a > val exists : ('a > bool) > 'a t > bool > val map : ('a > 'b) > 'a t > 'b list val map : ('a > 'b) > 'a t > 'b t val map_list : ('a > 'b) > 'a t > 'b list ? > val sort : ('a > 'a > int) > 'a t > unit > val filter : ('a > bool) > 'a t > unit > > val shuffle : 'a t > unit Hmm? What's that? > > val remove : 'a t > 'a > unit (* only one element removed, tested with > ( = ), raise Not_found *) > val remove_if : ('a > bool) > 'a t > unit > > (* indexes functions *) > > val index_of : 'a t > 'a > int (* raise Not_found *) > val at_index : 'a t > int > 'a (* raise Invalid_index *) > val index_of_with : ('a > bool) > 'a t > int (* raise Not_found *) > > val set : 'a t > int > 'a > unit (* raise Invalid_index *) set x n y takes O(n)? > val remove_at_index : 'a t > int > unit (* raise Invalid_index *) Ditto?  : Michal Moskal ::::: malekith/at/pldlinux.org : GCS {C,UL}++++$ a? !tv : PLD Linux ::::::: Wroclaw University, CS Dept : {E,w} {b++,e}>+++ h 
From: Stefano Zacchiroli <zack@bo...>  20030226 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 <fva@ts...>  20030226 09:58:23

John Max Skaller wrote: > >> My general philosophy on labels is that they should only be used when >> there is a real good reason to use them. What a 'real good reason' >> is I'm still working on. > > > > Good reason (1) is obvious: there are a LOT of arguments. > > Good reason (2) might be: there are several arguments of the same > > type and no natural order the programmer might guess at, or, > the chosen order differs from the C function it is wrapping. > > Good reason (3) is related to both: there are many arguments > and some are optional (so labels are necessary to invoke > the defaults). > > Another less good reason is: there are enough arguments > and lack of natural ordering, and the client is > likely to want to curry the function with subsets > of the arguments, perhaps multiple times. All seem to me good enough reasons. Shall we push it as a recommendation for contributions? But remember that some Standardlib functions come in two guises now: labelled and unlabelled. Regards. Fran Valverde 
From: John Max Skaller <skaller@oz...>  20030226 05:15:12

> My general philosophy on labels is that they should only be used when > there is a real good reason to use them. What a 'real good reason' is I'm > still working on. Good reason (1) is obvious: there are a LOT of arguments. Good reason (2) might be: there are several arguments of the same type and no natural order the programmer might guess at, or, the chosen order differs from the C function it is wrapping. An example might be: Array.make count value can be confused with Array.make value count without a type error if the array type is int array. Good reason (3) is related to both: there are many arguments and some are optional (so labels are necessary to invoke the defaults). Another less good reason is: there are enough arguments and lack of natural ordering, and the client is likely to want to curry the function with subsets of the arguments, perhaps multiple times.  John Max Skaller, mailto:skaller@... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61296600850 
From: Nicolas Cannasse <warplayer@fr...>  20030226 02:01:49

Hi extlist, Here's my mutable list interface. Implementation is available and mostly use the standard List library function. Mutable lists with in place modifications are very usable each time you were previously using "list ref" I'm not putting any documentation with the interface, since every not obvious function can be considered as to be removed or changed. It also provide a set of functions based on item index in the list ( i'm using this, but i'm not really sure it should be in the ExtLib MList... or perhaps in an inner module ) I'm waiting for your comments. Nicolas Cannasse  exception Invalid_index of int exception No_such_element module MList : sig type 'a t val empty : unit > 'a t val isempty : 'a t > bool val copy : 'a t > 'a t > unit val copy_list : 'a t > 'a list > unit val from_list : 'a list > 'a t val to_list : 'a t > 'a list val add : 'a t > 'a > unit val push : 'a t > 'a > unit val pop : 'a t > 'a (* raise No_such_element *) val last : 'a t > 'a (* raise No_such_element *) val first : 'a t > 'a (* raise No_such_element *) val npop : 'a t > int > 'a list (* raise No_such_element *) val clear : 'a t > unit val length : 'a t > int val add_sort : ('a > 'a > int) > 'a t > 'a > unit val hd : 'a t > 'a (* raise No_such_element *) val tl : 'a t > 'a list (* raise No_such_element *) val iter : ('a > unit) > 'a t > unit val find : ('a > bool) > 'a t > 'a val find_ex : ('a > bool) > 'a t > exn > 'a val exists : ('a > bool) > 'a t > bool val map : ('a > 'b) > 'a t > 'b list val sort : ('a > 'a > int) > 'a t > unit val filter : ('a > bool) > 'a t > unit val shuffle : 'a t > unit val remove : 'a t > 'a > unit (* only one element removed, tested with ( = ), raise Not_found *) val remove_if : ('a > bool) > 'a t > unit (* indexes functions *) val index_of : 'a t > 'a > int (* raise Not_found *) val at_index : 'a t > int > 'a (* raise Invalid_index *) val index_of_with : ('a > bool) > 'a t > int (* raise Not_found *) val set : 'a t > int > 'a > unit (* raise Invalid_index *) val remove_at_index : 'a t > int > unit (* raise Invalid_index *) end 
From: Nicolas Cannasse <warplayer@fr...>  20030226 01:47:04

Right now I see here some talks around about compilation and installation of ExtLib. I think that first we don't need to do such choice right now, and second that there is no choice to be made ! We're here talking about ExtLib, that'll be perhaps in the beginning ten to twenty files/modules with almost no inner depencies, all in the same directory, all wriiten in Ocaml  with no C stubs. I think we can afford making a source distribution with only a standard Makefile, and perhaps at least a bytecodebinary version for the current version of Ocaml. So please drop talks about Compiling and Installing tools. That discussion is currently held about the COAN project on the official list and have nothing to do with ExtLib. Nicolas Cannasse 
From: Nicolas Cannasse <warplayer@fr...>  20030226 01:39:41

> > The current goal is not to put every existing (although very used) ocaml > > library into the ExtLib. For example PXP, which is a very good XML parser  > > and everybody is using XML in today applications  should remain a separate > > library. The ExtLib should remain somehow small :) > > Huge libraries like GUI interface or 3D libraries should be on their > own. But unless we're talking megabytes of library here, I'd perfer to > download and install *one* library, not thirty. And, IMHO, XML parsing is > small enough and there are enough possible uses for it that I'd like it in > the library. Yes I agree, It would be good to add ( later ) a very small Xml parser into the ExtLib. But let's delay such choices a little bit more... Nicolas Cannasse 
From: Nicolas Cannasse <warplayer@fr...>  20030226 01:30:23

> >> 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. <snip> > Well, we should probably use ocaml script instead :) That's Ocamake, Thanks for your support John :) Nicolas Cannasse 