Here is the latest Caml Weekly News, for the week of October 30 to November 06, 2012.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-11/msg00005.htmlDeep in this thread, Jacques Garrigue explained:
Wow. I see that a big debate is going on mli files and declarations inside ml files. I think that lots of people have given this problem a lot of thought during many years. My conclusion has unfortunately been that trying to solve this at the language level without breaking backward compatibility is very difficult. For instance, one is currently allowed to do something like that: a.ml: let f x = x let b = f true a.mli: val f: int -> int This may look stupid, but this kind of code (of course more complicated) exists in the wild, and sometimes for sensible reasons. For this kind of reason, I do not see any easy way to import information from mli files to ml files. Now, is maintaining mli files really painful? In my experience, not at all. Taking as example the ocaml compiler itself, the only duplication that bothers me a little is the error type exported by many modules, as one always has to keep it in sync by copy-paste. This is a bit of a problem because for most uses this type could be abstract (you don't really care about its contents), but in some rare occasions you need it public. For other types, do not see syncing as a disadvantage, because it rather makes you conscious that other modules depend on this type, so better look at it twice :-) Of course I know that some people (probably with a different background) do not like mli files. Couldn't we just imagine a preprocessing tool that allows to generate both ml and mli from the same file? This is pretty standard for literate programming. It could even call the compiler if you want the types to be inferred automatically (even though I personally think that having to write value types in the mli file is good, because you know when you are changing an export.) As an external tool, it could use pragmas (keywords inside comments) for instance. Something close to ocamldoc (ocamldoc itself?) but which you would integrate in the compilation cycle. Anyway, I just wanted to state, from my experience, my lack of enthusiasm about modifying the core language to accommodate that.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-11/msg00008.htmlMike McClurg announced:
We're starting a functional programming group in Cambridge, UK, called NonDysFunctional. We're having our first meet up this Friday from 5pm to 9pm at the Old Spring Pub. Feel free to come at any time during that window. Citrix has kindly offered to pay for everyone's beer, so come thirsty! See our website for more information, including a map to the Old Spring: http://nondysfunctional.wikidot.com/blog:2 Also, we will be tweeting about future events on @nondysfun (https://twitter.com/nondysfun) If you think you might come, please email me, just so I have an idea of how many people might turn up. You don't have to register in order to come, however. Hope to see you there!He later added:
We had a successful meeting last Friday for our first Cambridge functional programmers meetup. As requested by those who turned up, I've created a meetup group to help us organize. If you are interested, please join here: http://www.meetup.com/Cambridge-NonDysFunctional-Programmers/ We're probably going to have another meeting in early December. It will probably just be another pub meetup. If you've got any requests for dates or for particular pubs, please let me know. Now that we've got an online home at meetup.com, I'll avoid spamming this list with future announcements.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-11/msg00011.htmlJeff Meister said:
I found an interesting (to me, anyway) use of OCaml's first-class modules, and particularly the new 4.00 type inference features, which I thought was worth sharing with the list. This has probably been observed by someone else already, but I haven't seen it discussed. In the OCaml standard library, the polymorphic set data structure is implemented as a functor, which takes a module containing a type t and total ordering function over t, and returns a module representing sets whose elements have type t. Like so: module StringSet = Set.Make(String) module CharSet = Set.Make(Char) One disadvantage of this method is that once the functor has been called, the type of the set elements is fixed. As a consequence, OCaml's set interface has no map function. If we had a polymorphic type like 'a set, this function would have type 'a set -> ('a -> 'b) -> 'b set. But StringSet.t and CharSet.t are not polymorphic; the corresponding type elt in each module cannot be changed. However, using first-class modules, we can write a function map for sets, which takes as an extra argument the packaged module representing the set we're mapping from. Maybe this function is better called map_from. Check it out: # module Set = struct module type OrderedType = Set.OrderedType module type S = Set.S module Make(Ord : OrderedType) = struct include Set.Make(Ord) let map (type e') (type t') (module OtherSet : S with type elt = e' and type t = t') os f = OtherSet.fold (fun x accu -> add (f x) accu) os empty end end;; [... bunch of output ...] val map : (module S with type elt = 'a and type t = 'b) -> 'b -> ('a -> elt) -> t Now, back in OCaml 3.12, this function could be written (without the nice package-expanding pattern I've made use of), but calling it was quite a pain, enough to invalidate the whole enterprise. One would have to type this: # let strs = StringSet.(add "foo" (add "bar" empty));; val strs : StringSet.t = <abstr> # let chrs = CharSet.map (module StringSet : Set.S with type elt = StringSet.elt and type t = StringSet.t) strs (fun s -> s.);; val chrs : CharSet.t = <abstr> It's much easier with the type inference changes in OCaml 4.00: # let strs = StringSet.(add "foo" (add "bar" empty));; val strs : StringSet.t = <abstr> # let chrs = CharSet.map (module StringSet) strs (fun s -> s.);; val chrs : CharSet.t = <abstr>
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-11/msg00028.htmlXavier Clerc announced:
This post announces the 1.3 release of the Bisect project, whose goal is to provide a code coverage tool for the OCaml language. Home page: http://bisect.x9c.fr Main changes since 1.2: - new instrumenter based on '-ppx' - new '-summary-only' to output only summary (text mode only) - refactoring, including minor bugfixes - bug#86: '-ocaml-prefix' doesn't really work - bug#87: install shouldn't build anything - bug#89: do not activate warnings by default
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-11/msg00033.htmlDiego Olivier Fernandez Pons asked and Fabrice Le Fessant replied:
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the recent posts from the ocamlcore planet blog at http://planet.ocamlcore.org/. RTT: https://forge.ocamlcore.org/projects/rtt/ Bisect: 1.3: https://forge.ocamlcore.org/forum/forum.php?forum_id=866 Dropbox-as-a-Database, the tutorial: http://blog.opalang.org/2012/11/dropbox-as-database-tutorial.html Dropbox-as-a-Database: http://blog.opalang.org/2012/10/dropbox-as-database.html Generic Graphml Printer for OcamlGraph: https://mancoosi.org/~abate/generic-graphml-printer-ocamlgraph
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.