From: Martin J. <mar...@em...> - 2004-04-30 08:15:10
|
On Thu, 29 Apr 2004, Nicolas Cannasse wrote: > > I am still curious to see in what kind of situations you would use them. > > Please give us some examples. > > The rational of Enums is the following : > - we have increasing numbers of containers (list, arrays, dynarrays, > hashtbl, pmap, .... ) > - all theses containers need to implement all the functionnal ops : map, > iter, fold... > - conversions between each of the containers is a O(n^2). Usually it is O(n) or O(n log n). > - enums are here to provide an easy way to convert between different > containers, and to abstract them at the same time when using functionnal > ops. > There is nice side effects about their lazyness : > - you never need to allocate intermediate data structure when filtering / > mapping > - you can work with a large collection of elements without any problem. > > For example, let's take a 1 M elements list. > Each map will duplicate it into a brand new 1 M elements list. > With enums you can stack several maps and filters, and then at the end, when > you iter or fold, each readed element will go through your functionnal > stack, be mapped or filtered by it, and eventually reach the output. Here is a simple example: let l2 = List.map f1 l1 in let l3 = List.filter f2 l2 in let l4 = List.map f3 l3 in ... You can replace it by: let l4 = List.fold_left (fun accu x -> let y = f1 x in if f2 y then f3 y :: accu else accu) l1 in ... In both cases, the memory is kept constant (2 * n) during the process but in the second version, less memory is allocated/deallocated. Of course List may be replaced by any other module. If you don't want to iterate until the end, just raise an exception: let fold_while f test s init = let result = ref init in try fold (fun accu x -> if test x then f x accu else (result := accu; raise Exit)) [] s with Exit -> !result > Better : you can input to your algorithm some data coming from a list, a > socket, an array, a file, or the container you need. Write once, use N > times, where N is the number of "sources" for your data. > If you're not convinced by this I don't know what I can add... Some real code! > > I can give several examples for the Hashtbl stuff that I already posted, > > and I don't expect it to be at the core of the future "standard" library > > for the Objective Caml language. > > Samples are not enough. I personaly prefer rationals. ROTFL > > I don't know what you plan to do about Int, Float and Bool additional > > modules, or with tables of properties, as recently proposed by other > > posters. > > Int , Float and Bool are useful with functors. ExtLib is functor-free and > happy with it. Functors exist and will continue to be used! > Functors were already discussed and dismissed before : please > watch the archives. Please give a clear reference. > The tables of properties are nice but IMHO are requiring more typing. I don't understand your sentence. > > And why don't you merge the project with the other ExtLib? > > This is out-of-question. Other ExtLib use C code and ExtLib is pure OCaml. The current standard lib uses C code too. Try first to remove all the "include" from modules of the standard library, and see if you can rewrite the missing parts in pure OCaml. > > If you don't trust other people's work, the result will be that someone > > else will decide to start one more general library project. > > I do trust, when there is some strong arguments in favor of an addition to > the ExtLib : if I let everything end up into the ExtLib without some > filtering and previous discussions over the usabality and general use of the > stuff then it will grow like the Java library : big and unusable. Small and > consistent is better. The current standard library is perfect then. Bye, Martin |