Here is the latest Caml Weekly News, for the week of 04 to 11 January, 2005.
Archive: http://caml.inria.fr/archives/200501/msg00028.htmlMaas-Maarten Zeeman announced:
I'd like to announce the move of the OUnit website. Please update your bookmarks. The new web-site is at: http://www.xs4all.nl/~mmzeeman/ocaml
Archive: http://caml.inria.fr/archives/200501/msg00029.htmlMaas-Maarten Zeeman announced:
I'd like to announce the release of Ocaml-Event-0.5.0, Ocaml bindings for the libevent API. http://www.xs4all.nl/~mmzeeman/ocaml/ The libevent API provides a mechanism to execute a callback function when a specific event occurs on a file descriptor or after a timeout has been reached. Furthermore, libevent also support callbacks due to signals or regular timeouts. Currently, libevent supports /dev/poll, kqueue(2), select(2), poll(2) and epoll(4). The internal event mechanism is completely independent of the exposed event API, and a simple update of libevent can provide new functionality without having to redesign the applications. As a result, Libevent allows for portable application development and provides the most scalable event notification mechanism available on an operating system.
Archive: http://caml.inria.fr/archives/200501/msg00030.htmlMaas-Maarten Zeeman announced:
I'd like to announce Ocaml-Expat-0.9.0, Ocaml bindings for the Expat XML Parser. http://www.xs4all.nl/~mmzeeman/ocaml/
Archive: http://caml.inria.fr/archives/200412/msg00327.htmlJean-Baptiste Rouquier said:
> Is there a library that implements a parser > for configuration files similar to the *.ini > files from windows? For instance: > > [section 1] > key1 = value1 > key2 = value2 > > [section 2] > key3 = value3 > key4 = value4 > key5 = value5 Inifiles (http://www.csun.edu/~eric/inifiles-1.0.tar.gz) is explicitely designed to parse this file format. I also suggest my own lib, Config_file, available at http://savannah.nongnu.org/download/cameleon/ . It allows comments, command lines options identical to file options (based on Arg), arbitrary nesting of subsections, error logging and a few more features.
Archive: http://caml.inria.fr/archives/200501/msg00033.htmlRichard Jones asked:
I'm looking for a 3D vector library for OCaml. In particular I'm interested in: * points, rays, vectors, surfaces * intersection of sphere and ray, surface and ray, etc. Simple enough to write myself, but I was hoping that one would already exist. I checked the Humps, and the nearest I could find are GeOCaml, which seems to be 2D only, and SOCaml which is the OCaml interface to Open Inventor, which is not quite what I'm looking for.Sachin Shah answered:
I am not sure if this exactly fits your needs, but PsiLAB (http://psilab.sourceforge.net/) is available for the types of mathematical operations you are talking about. At the very least, it provides extensive matrix/linear algebra operations, which you could use to write your own (assuming another is unavailable).Jon Harrop suggested and Richard Jones replied:
> Sounds like ray-tracing territory. IIRC there was an ocaml > ray-tracer entry to one of the old ICFP contests. I suspect the > source is available and should fill many of those holes. Thanks - I found the source to the ray tracer (http://caml.inria.fr/icfp00-contest/) which is very useful. > Will this be performance critical? I'm just messing around with some 3D scene stuff ...Lars Nilsson added:
There's also a raytracer written in O'Caml available at http://user.it.uu.se/~jenso/programming/
Archive: http://caml.inria.fr/archives/200501/msg00038.htmlAleksey Nogin announced:
The OMake Team is proud to announce a new release of the OMake Build System - OMake 0.9.4. OMake is a build system, similar to GNU make, but with many additional features: o Support for large projects spanning several directories or directory hierarchies. o Comes with a default configuration file providing support for OCaml, C and LaTeX projects, or a mixture thereof. Often, a configuration file is as simple as a single line OCamlProgram(prog, foo bar baz) which states that the program "prog" is built from the files foo.ml, bar.ml, and baz.ml. o Fast, reliable, automated dependency analysis using MD5 digests. o Portability: omake provides a uniform interface on Win32 and on Unix systems including Linux and Mac OS X. o Builtin functions that provide the most common features of programs like grep, sed, and awk. These are especially useful on Win32. o Full native support for rules that build several things at once (such as ocamlopt building .cmx and .o). o Active filesystem monitoring, where the build automatically restarts whenever you modify a source file. This can be very useful during the edit/compile cycle. o A companion command interpreter, osh, that can be used interactively. The home site for OMake is http://omake.metaprl.org/ OMake version 0.9.4 contains a large number of enhancements and bug fixes, including: - Portability improvements. OMake should now compile and work under Windows 2000, Windows NT and FreeBSD. A number of Windows-specific bugs are fixed. A Windows installer is added. - OMake now uses the built-in versions of the following commands: cp, mv, mkdir, rm, rmdir, chmod - Improvements to the filesystem watch functionality. In particular, the build will now restart if a change to one of the OMakefiles is detected. - Added a USE_OCAMLFIND variable that can be used to force or prohibit the usage of ocamlfind in a project (by default USE_OCAMLFIND is set to true iff the ocamlfind executable is found in path). - Added a "--force-dotomake" option to create all .omc and .omo files under $HOME/.omake/cache and a "--dotomake" option to specify an alternative to $HOME/.omake - Added :squash: dependencies (that specify that a dependency must be built, but when the dependency changes, it does not cause the target to be rebuilt). - OMake will now read ~/.omakeinit and ~/.omakerc files on startup. - Improved the latex-related rules. - Documentation improvements. - Bugs fixed: 142, 153, 311, 313, 314, 316, 332, 333, 339, 350, 360, 361, 366, 367, 368, 374, 375. See http://bugzilla.metaprl.org/buglist.cgi?bug_id=142,153,311,313,314,316,332,333,339,350,360,361,366 ,367,368,374,375 for details. OMake 0.9.4 is still an alpha release. While we have made an effort to ensure that it is bug-free, it is possible some functions may not behave as you would expect. Please report any comments and/or bugs to the mailing list omake at metaprl.org and/or at http://metaprl.org/bugzilla OMake is distributed under the terms of the GNU General Public License. OMake configuration files are distributed under the terms of an MIT-like license. OMake sources, as well as a number of Linux and Windows binaries are available from the OMake home page at http://omake.metaprl.org/
Archive: http://caml.inria.fr/archives/200501/msg00046.htmlSomeone asked:
I just got from LISP to OCaml, and wondered if there is an equivalent of generic functions from LISP (CLOS) in OCaml. In the Common Lisp Object System methods don't belong to certain objects/classes. They are just function specializing on the argument types. So basically I want to write something like: let foo (x : int) = x*x;; let foo (x : float) = x*.x;; This, obviously, will not work since foo is just redefined by the second statement. One would think, that having methods not being belonging to objects/classes, is rather pointless. Well 95% of the time, there is no necessity for that. But in the other 5%, it is really helpful.Richard Jones answered:
The general solution is GCaml (http://pauillac.inria.fr/~furuse/generics/README.gcaml) which is not part of OCaml core.Brian Hurt also answered:
The short answer is no. For two reasons- first, Ocaml doesn't keep type information (in most cases) of data at run time, the type information is used during compilation and then tossed. Which means that Ocaml doesn't have a way at run time to tell which version of the function to call. And second, and more importantly, overloading (like you're doing above) would make type inference extremely difficult if not impossible. There are several ways to "work around" this limitation in Ocaml, depending upon what exactly you are doing. 1) Just use different functions. Do: let ifoo x = x * x;; let ffoo x = x *. x;; and just call the correct one. This is generally not as bad a solution as you might think. 2) Use variant types: type number = Int of int | Float of float;; let foo = function | Int(x) -> Int(x*x) | Float(x) -> Float(x*.x) ;; The tags in this case are the type information Ocaml would normally "throw away". 3) Use modules: module type Mult = sig type t val mul : t -> t -> t end module type Foo = sig type t val foo : t -> t end module Make(M: Mult) : Foo with type t = M.t = struct type t = M.t let foo x = M.mul x x end;; module IMult = struct type t = int let mul x y = x * y end;; module IFoo = Make(IMult);; module FMult = struct type t = float let mul x y = x *. y end module FFoo = Make(FMult); For this simple example, modules and functors are clunky- but they allow the user of your code to create new foo functions, which is usefull. With the exception of certain artificial contests (Paul Graham) I've never met a real world problem that needed overloading, or even benefitted signifigantly from overloading that didn't benefit just as much or more from one of the solutions above.Someone added:
> 3) Use modules: .... I would add 4) use objects. see http://caml.inria.fr/ocaml/htmlman/manual005.html and define a class ofloat, and oint (for object float and objects int) and define let foo x = x#mul x Note that foo does not have to belong to the classes. It can be defined outside of the class defintion. Of course if your definition of foo would have been let foo (x : int) = x+x;; (* * have been replaced by + *) let foo (x : float) = x*.x;; then, it does not work anymore. > > With the exception of certain artificial contests (Paul Graham) I've never > met a real world problem that needed overloading, or even benefitted > signifigantly from overloading that didn't benefit just as much or more > from one of the solutions above. I guess that's because you never been involved in real world problems. Overloading, which is adhoc polymorphism is as useful as parametric polymorphism. Ask the haskell folks if they would accept to forget about type classes. Of course functors can emulate some of the advantages of overloading, but not totally. Objects are better for this.John Skaller also answered:
Felix is an ML like language which does provide overloading. It does overload resolution at compile time. As Brian mentions this makes full type inference hard, however this isn't nearly so much of a problem as you might think You have to annotate function argument types, however function return types and variable types are still deduced. For this extra effort you get three positive benefits: (a) better documented code (b) better diagnostic messages on type errors (c) overloading In addition, some of the newer Ocaml features like polymorphic variants require type annotations or coercions to be used at times anyhow, and such annotation is common for functions in separately compiled files, which often have interface specifications (which require type annotations). The two principal advantages of inference would appear to be: (a) for quick and dirty code and small functions where the extra clutter would reduce clarity and increase coding time. (b) for complex functions with nasty types The brevity argument is context dependent. I have just written in Felix a function which converts a complex parse tree into a string. This function has to decode around 100 variants from 40 or so types to produce the result. In Felix all these functions are called 'str', and I can just write code like fun str : product_list_t -> string = | product_list_1 (?s,?sl) => str s + " * " + str sl | product_list_2 ?s => str s ; fun str : term_t -> string = | term_1 (?t,?p) => str t + " / " + str p | term_2 (?t,?p) => str t + " % " + str p | term_3 ?pr => str pr ; ... Without overloading I would have to invent a discrete name for each function, which would certainly reflect the argument type, so this is balances out in favour of overloading. In the actual use of the function there is no doubt that overloading is briefer than inference without it, since I can use the 'str' name without knowing which function is applied. In Ocaml, this program would be almost untenable. I would try to avoid this problem by using polymorphic variants instead of ordinary ones (and then write one big 'str' function for all the variants). Bottom line: I have used two similar languages, one with type inference and one with overloading, and in general I could pick between them like this: Overloading (in the Felix and C++ style) only works on direct calls where the function is named. It doesn't work with closures, for example variables containing function values, including parameters. So I would say inference is better when you're doing lots of higher order work, and overloading is better for more mundane industrial applications. BTW: it would be interesting to provide a better integration of both features. G'Caml is one idea. Polymorphic variants are another. In Felix you can write: fun swap(x,y) => y,x; without type annotations: type variables are assumed but they're independent. This precludes code like fun apply(f,x)=> f x; but it is clear some localised inference in this case would allow this. It is also known that overloading CAN work with inference with some contraints -- there is a paper somewhere on Citeseer on this topic (sorry don't have the URL at the moment, if someone finds it please let me know..)Alex Baretta said:
> With the exception of certain artificial contests (Paul Graham) I've never > met a real world problem that needed overloading, or even benefitted > signifigantly from overloading that didn't benefit just as much or more > from one of the solutions above. As a member of the International Caml's Jihad, I'd like to spend two cents of dynamite on this topic: type inference is as good as honey in large scale industrial projects, where sometimes the typing of complex recursive polymorphic algorithms is not evident until you get the printout from the compiler or the toplevel. Thank you, O great Unification Algorithm. But, then again, extensional polymorphism is also a much needed feature. In my company we depend heavily on on extensional polymorphism to create exstensibile functions. We have implemented this on top of explicitly polymorphic types: i.e. polymorphic variant types. Let us all faithfully await the Coming of the the Gcaml... And meanwhile let us use polymorphic variants to get the same effect. type poly_int = [ `Int of int ] type poly_float = [ `Float of float ] let foo_int foo = function | `Int x -> `Int(x * x) | other -> foo other let foo_float foo = function | `Float x -> `Float(x *. x) | other -> foo other let rec foo x = match x with | #poly_int -> foo_int foo x | #poly_float -> foo_float foo x All hail Ocaml! Alex, after too many nights spent writing typechecking code...Olivier Andrieu said and Alex Baretta answered:
> Hum, I would have written this in that way : > ,---- > | let foo_int (`Int x) = `Int (x * x) > | let foo_float (`Float x) = `Float (x *. x) > | > | let foo = function > | | #poly_int as x -> foo_int x > | | #poly_float as x -> foo_float x > `---- > > What's the use for the `other -> foo other' clauses ? In my previous post I mentioned *extensible functions*. The first parameter of single instances of the polymorphic foo (i.e. foo_int and foo_float) allow the generalization of each of these to arbitrarily complex polymorphic type schema. We have exactly 7888 lines of code which contain such late-bound-recursive functions Ã la foo_int. Obviously it takes a relatively complex example to show why late-bound-recursion is essential to the implementation of a fairly extensional polymorphism with Ocaml's polymorphic variants.And the thread continued ...:
I invite the interested readers to read the rest in the archive, the thread starts at http://caml.inria.fr/archives/200501/msg00046.html
Archive: http://caml.inria.fr/archives/200501/msg00053.htmlChristophe Troestler asked and Gerd Stolpmann answered:
> The new Str module not only made it LGPL but also very fast (100% more > than Pcre in some cases). However it is still not thread safe -- and > it is not possible given its interface. However, from a quick look, > it seems to me that what is under the hood is almost thread safe. So > why not to write a new module (say Regexp) which would be thread safe > and on top of which Str would be build? This would not be too much > work, would it? The Netstring_str module (part of ocamlnet) does it the other way round: The thread-safe interface is built on top of a potentially unsafe implementation. Although the current version of Netstring_str uses Pcre as its implementation, there is a historic version on top of Str. This other way of layering can be made working because there is the global master lock protecting the C parts of the regexp engine. The interface of Netstring_str: http://ocamlnet.sourceforge.net/manual/refman/Netstring_str.html Of course, this is not the optimal solution, I would prefer it the way you suggest.Xavier Leroy answered, causing many replies in the thread:
> The new Str module not only made it LGPL but also very fast (100% more > than Pcre in some cases). However it is still not thread safe -- and > it is not possible given its interface. However, from a quick look, > it seems to me that what is under the hood is almost thread safe. You are correct: the regexp compiler (written in Caml) and the execution engine (written in C) are thread-safe, it's only the API (in Caml) that uses global state. > So why not to write a new module (say Regexp) which would be thread > safe and on top of which Str would be build? That's a very good idea. My initial plan was to have two APIs, the old Str for compatibility and a newer, better designed one for new programs. Besides being thread-safe, the new API could also expose the abstract syntax tree for regexps, allowing easier construction of complex regexps by programs than can be done by working at the level of the string representation of regexps. It's just that I never got to design that new API :-( > This would not be too much work, would it? The implementation work should be quite small indeed, but don't underestimate the work needed to design the API. API design is harder than it seems... But if a few persons on this list want to team up to design an API, that would be wonderful indeed. (A small group is better than individual designers in that several pairs of eyes spot inconsistencies better.)
Archive: http://caml.inria.fr/archives/200501/msg00045.htmlRadu Grigore asked and Christian Lindig answered:
> Is there any document describing some decisions involved in choosing > the right data structures for representing the OCaml parse tree? Is > there any document describing some idioms that are common in the fp > world? > > I work on translators using C++ and I'd like to learn from other approaches. I suggest to look at CIL, an infrastructure in OCaml for ANSI C. http://manju.cs.berkeley.edu/cil/
> Can anyone tell me if it is possible to open two graphic windows in ocaml? I > would like to have something like a popup window that shows additional > information when clicking on specific regions in the initial graphics > windows. You might want to migrate to a "proper" solution sooner rather than later. After all, you might also soon want to add buttons and menus. Have a look at lablgtk2, here: http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html It supports a very capable canvas widget.
Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).
If you know of a better way, please let me know.
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.