Here is the latest OCaml Weekly News, for the week of February 07 to 14, 2017.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-02/msg00036.htmlJeremy Yallop announced:
Readers of caml-list may be interested to know that the joint post-proceedings of the 2015 ML and OCaml workshops have now been published: http://eptcs.web.cse.unsw.edu.au/content.cgi?ML2015 Of the four papers in the volume, three are directly relevant to OCaml users: * Generating Code with Polymorphic let: A Ballad of Value Restriction, Copying and Sharing (Oleg Kiselyov) describes a translation from a MetaOCaml-style multi-staged language into a language without staging, with support for generating polymorphic-let expressions. * GADTs and Exhaustiveness: Looking for the Impossible (Jacques Garrigue and Jacques Le Normand) explores the difficulties with checking pattern-matching exhaustiveness for GADTs in the presence of abstract types. The paper includes details of the "refutation patterns" introduced in OCaml 4.03. * Specialization of Generic Array Accesses After Inlining (Ryohei Tokuda, Eijiro Sumii and Akinori Abe) describes an optimization in the OCaml compiler that extends the intermediate language with array type information to avoid runtime type dispatch. and the fourth falls within the broader area of ML-family languages: * Dependent Types for Multi-Rate Data Flows in Synchronous Programming (William Blair and Hongwei Xi) describes an implementation of the synchronous programming language Prelude using the type system of the ML-family language ATS. With kind regards, Damien Doligez Jeremy Yallop (editors)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-02/msg00040.htmlEray Ozkural announced:
---> https://github.com/examachine/parallpairs Parallel all-pairs similarity search algorithms in OCaml If you use this code, please cite the following paper. It is currently under review at IJPP. https://arxiv.org/abs/1402.3010 1-D and 2-D Parallel Algorithms for All-Pairs Similarity Problem Eray Özkural, Cevdet Aykanat (Submitted on 13 Feb 2014) All-pairs similarity problem asks to find all vector pairs in a set of vectors the similarities of which surpass a given similarity threshold, and it is a computational kernel in data mining and information retrieval for several tasks. We investigate the parallelization of a recent fast sequential algorithm. We propose effective 1-D and 2-D data distribution strategies that preserve the essential optimizations in the fast algorithm. 1-D parallel algorithms distribute either dimensions or vectors, whereas the 2-D parallel algorithm distributes data both ways. Additional contributions to the 1-D vertical distribution include a local pruning strategy to reduce the number of candidates, a recursive pruning algorithm, and block processing to reduce imbalance. The parallel algorithms were programmed in OCaml which affords much convenience. Our experiments indicate that the performance depends on the dataset, therefore a variety of parallelizations is useful. The code is quite interesting, as it shows how to effectively use OCaml for MPI code. There is a bunch of well-written parallel functional code that I will extract from this codebase and release separately. You need the latest ocamlmpi release as that contains the patches I made to make this code work. This code is released under AGPL-3.0. Please do not ask me to release it under BSD license. If you need a commercial license, you should purchase it. Happy hacking!
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-02/msg00053.htmlLouis Gesbert announced:
We are please to announce that the beta of Opam 2.0.0 is out! You can read the full announcement here: https://opam.ocaml.org/blog/opam-2-0-beta/ Highlights of the beta, as compared to the previous alpha version, include: - The new 'opam build' command, to compile source trees directly - Support for repository signing through the external Conex¹ tool Please try it out, and let us have feedback!
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-02/msg00057.htmlVincent Balat announced:
The Ocsigen team is very happy to announce the first release of two new major projects: - Ocsigen Start: a Web/mobile application skeleton written with Js_of_ocaml and Eliom, that you can use as a basis for your own app or to learn Web/mobile app programming in OCaml, - Ocsigen Toolkit: a set of responsive widgets for your mobile and Web applications in OCaml. Both projects are available on Opam and released under LGPL. Before installing, you can test an online version of Ocsigen Start here: http://ocsigen.org/ocsigen-start/demo/ The demo application for Android is available in Google Play store: https://play.google.com/store/apps/details?id=com.osdemo.mobile If you prefer, you can install it manually using the apk file: http://ocsigen.org/ocsigen-start/demo/osdemo.apk iOS version is also available here: http://ocsigen.org/ocsigen-start/demo/osdemo-ios.tgz (to be installed via XCode). Ocsigen Start provides the basic features for user management (registration, activation links, password recovery, etc), and some useful libraries. Remove the parts you don't need for your own app. Ocsigen Start also contains many examples of code: remote procedure calls, push notifications from server, reactive pages, database interaction, session data, internationalisation, and some widgets from Ocsigen Toolkit. Ocsigen Toolkit contains common widgets for mobile and Web apps, written natively in OCaml and specifically designed for Eliom's multi-tier and multi-platform programming style. You can also use them in client-only Js_of_ocaml programs. Many new widgets will be added in future versions. Ocsigen Start and Ocsigen Toolkit are developed by the Ocsigen team at Be Sport and Univ. Paris Diderot/IRILL.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-02/msg00058.htmlSteffen Smolka asked:
Is it possible to create namespaces inside an object? Concretely, I would like to write class buffer = object(self) ... method get = ... module Latin1 = struct method get = ... end module Utf8 = struct method get = ... end end so that given an object b : buffer, I can call methods b#get b#Latin1.get b#Utf8.get Declaring modules inside an object seems to be illegal, though. Is there any way to achieve something along those lines? Is there a better way to structure things?Jeremy Yallop replied:
It's possible to achieve something like this using methods that return objects. If your nested objects don't need to access the internal state of the parent then you might write it like this: class buffer = let latin1 = object method get = ... end and utf8 = object method get = ... end in object(self) ... method get = ... method latin1 = latin1 method utf8 = utf8 end With this approach you can write b#get b#latin1#get b#utf8#get which, apart from some minor orthographic differences, looks like what you were aiming for. Your intuition that this isn't really idiomatic OCaml is right, though. In OCaml, unlike some other languages with classes and objects, classes are not usually used as namespaces; method names are globally (or, rather, "ambiently") scoped, and there's no real support for the kind of nesting that you're interested in. Instead, people typically build nested namespaces using modules: module Buffer = struct let get = ... module Latin1 = struct let get = ... end module Utf8 = struct let get = ... end end With the module approach you write the 'receiver' after the 'method' rather than before, but that doesn't seem like a huge hardship. (10% of the world manages to get by with VSO languages.) Buffer.get b ... Buffer.Latin1.get b ... Buffer.Utf8.get b ... If you're keen to stick with objects there are slightly more idiomatic ways to make it work. You could, of course, replace the '.' with a '_' and define methods 'latin1_get', 'utf8_get' in place of 'Latin1.get', 'Utf8.get'. Or you could select the encoding using a variant type: type enc = Latin1 | Utf8 class buffer = object (self) method get = function | Latin1 -> ... | Utf8 -> ... end Of course, the order of the words in an invocation changes again, but there's no real increase in complexity for the caller: b#get Latin1 b#get Utf8 This last approach can be taken quite far -- for example, you could enrich the type 'enc' so that the return type of 'get' varies according to the encoding.Steffen Smolka then said:
Thanks for the detailed answer, Jeremy! > If you're keen to stick with objects Yes, I rely on inheritance and dynamic dispatch for what I have in mind. (This is actually the first time I'm touching the dark object oriented side of OCaml :) ) To give some more context, I am refactoring some code that uses modules and no objects. The reason I want to move to objects is that I want to derive a slightly enhanced module from some base implementation. Inheritance + dynamic dispatch allow me to do so with very little trouble: I can simply overwrite a few methods from the base implementation. I suppose I could achieve the same by turning the base module into a functor, and abstracting over the functions that my enhanced implementation needs to replace. I think it won't be quite as natural, but I'll give that a try. > Or you could select the encoding using a variant type: Good idea, and I'm happy with the syntax for the caller. But I'm more concerned with the organization of the code; this would mix the Latin1 and Utf8 implementations. I would rather keep them separate.Gerd Stolpmann then said:
First-class modules could also be an option: Let's assume both the base module and the modified one can use the same module type: module T = sig ... end Now, define the base module like module Base : T = ... end then, define the modified one: module Mod : T = include Base ... now override what you need to change but note that there's no dynamic dispatch ... end Of course, you could also use functors for making these modules. Now turn this into first-class modules and pass them around: let base = (module Base : T) let mod = (module Mod : T) The syntax for unpacking the module is quite cumbersome: let module M = (val base : T) in M.function ... Unfortunately, there's nothing simple like base.function. Compared with objects you get: * You can also put types and (to some degree) modules into these "code containers" * However, there's no dynamic dispatch except you arrange explicitly for that, e.g. with references to functions * Generally, a heavier syntax, but it might be okSteffen Smolka then said Yaron Minsky replied:
> Yeah, I have seen that there is support for first class modules, that's > pretty cool stuff! > I do need dynamic dispatch, though. I've always been a bit confused about what the term "dynamic dispatch" means, but don't first class modules provide what you want? After all, when you write: let f (module M : S) x = M.g x the specific function M.g is determined dynamically, depending on which first class module is passed into f.Steffen Smolka replied:
Right....but you have to explicitly make that choice when you implement `f`. With objects on the other hand, somebody may write a base implementation c: class c = object(this) method foo = ... this#bar ... method bar = ... this#foo ... (* original definition *) end Later on, somebody else may refine this implementation by overwriting c#bar: class c2 = object(this) inherit c method bar = ... (* new definition *) end Now c2#foo will invoke the new definition of bar, even though the author of `c` may have never anticipated this (and did not have to account for this possibility when he defined foo). So, I would say "dynamic dispatch" plus inheritance give you the ability to extend modules in ways that weren't necessarily anticipated by the original author of the module. And yet all the code written by the original author will work with your extended version of the module.Yaron Minsky then remarked:
Sure. And if that's what you want, objects seem like the right solution. That said, I find this style hard to think about, since it involves breaking ordinary notions of abstraction. The more explicit style where you use functors (or functions, if using first class modules) to parameterize code feels cleaner and easier to reason about to, though it does have some more syntactic overhead.Leo White also remarked:
I think it would be more correct to say that you want open recursion. Classes are the easiest way to get that in OCaml, and they indeed use dynamic dispatch and inheritance, but there are other mechanisms that provide open recursion. For example, most proposals for "mixin modules" support open recursion but I wouldn't say they use dynamic dispatch.Evgeny Roubinchtein then asked and Markus Mottl replied:
> Apologies in advance for my ignorance, but is there some reference(s) you > could point me to where the notion of "open recursion" is defined? I am > pretty sure I understand "dynamic dispatch." Lets first see what closed recursion typically looks like: type t = Num of int | Add of t * t let rec eval = function Num n -> n | Add (x, y) -> eval x + eval y This type cannot be extended recursively with another operation, say "Sub" for subtraction, because "Add" only takes arguments of type "t", i.e. it only permits "Num" and "Add" under itself. If you want to permit extensibility, you have to "break" the recursion, leaving it open. This can be done by introducing a type variable that captures extensions to the datastructure, and an extra evaluation function argument to "eval" to deal with the evaluation of extensions. Polymorphic variants make implementations of open recursion much more elegant than regular variants. You can check out a simple example for the above problem here: https://github.com/mmottl/ocaml-prog-pats/blob/master/extensible_ast/ast.mlLeo White also replied:
A google search will probably produce some reasonable definitions, but for a more precise treatment I think you can look in Chapter 18 of "Types and Programming Languages".
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-02/msg00059.htmlFrancois Berenger announced:
I am pleased to announce the very first official release of Hoogle for OCaml programmers. The project page is here: https://github.com/UnixJunkie/hoogle_for_ocaml The tarball is here: https://github.com/UnixJunkie/hoogle_for_ocaml/archive/v1.0.0.tar.gz
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-02/msg00080.htmlSimon Cruanes announced:
It is my great pleasure to announce the release of Containers 1.0, after almost four years of development. Containers is a modular, clean and powerful extension of the OCaml standard library, under the permissive BSD license. It is designed to be efficient, light on link-time dependencies, and to complement the existing modules rather than replacing them. The core library has no dependency on unix and should be usable everywhere. Every module is independent and is prefixed with 'CC' in the global namespace. Alternatively, `open Containers` will bring enhanced versions of the standard modules into scope, along with a few modules that should exist, such as Option, IO or Int. Containers now requires OCaml >= 4.01. Containers also features sub-libraries for helping with threads, S-expressions, and some unix utilities to invoke sub-processes. I jump on the opportunity to thank the various users and contributors that helped improving the code, kept asking for better solutions, and reported bugs. Cheers! github page: https://github.com/c-cube/ocaml-containers documentation: http://c-cube.github.io/ocaml-containers/1.0/ overview of 1.0: https://github.com/c-cube/ocaml-containers/issues/84
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-02/msg00086.htmlHongbo Zhang announced:
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-02/msg00090.htmlBruno Bernardo announced:
The first OUPS meetup of 2017 will take place on Tuesday, Feb. 21, 7pm at IRILL on the Jussieu campus. As usual, we will have a few talks, followed by pizzas and drinks. The talks will be the following: - Jacques Garrigue on GADTs and missing cases : searching for the impossible - Vincent Balat on Ocsigen Start : Quick web and mobile apps in OCaml - Benoit Rognier on Edukera : a web app for teaching maths. Please do note that we are always in demand of talk *proposals* for future meetups. To register, or for more information, go here: https://www.meetup.com/ocaml-paris/events/236894273/ *Registration is required! Access is not guaranteed after 7pm if you're not registered.* (It also helps us ordering the right amount of food.) Slides from previous sessions are available online: https://www.meetup.com/ocaml-paris/files/ Access map: IRILL - Université Pierre et Marie Curie (Paris VI) Barre 15-16 1er étage 4 Place Jussieu 75005 Paris https://www.irill.org/pages/access.html The meetup organizers.
Here is a sneak peek at some potential future features of the Ocaml compiler, discussed by their implementers in these Github Pull Requests. - Adding a new field to record `formatter_out_functions` to redefine the meaning of indentation https://github.com/ocaml/ocaml/pull/595 - Symbolic formatted pretty-printing https://github.com/ocaml/ocaml/pull/615 - User-defined indexing operator without array indexing https://github.com/ocaml/ocaml/pull/622 - API changes for multicore https://github.com/ocaml/ocaml/pull/1003 - Merge Unix and Windows build systems in the root directory https://github.com/ocaml/ocaml/pull/1033 - Implemented `List.init` https://github.com/ocaml/ocaml/pull/1034 - Improve tools/read_cmt https://github.com/ocaml/ocaml/pull/1036 - PR#7478: ocamldoc, avoid module preambule repetion https://github.com/ocaml/ocaml/pull/1037
Here are links from many OCaml blogs aggregated at OCaml Planet, http://ocaml.org/community/planet/. Ocsigen Start and Ocsigen Toolkit reach 1.0! https://ocsigen.github.io/blog/2017/02/09/start/ opam 2.0 Beta is out! https://opam.ocaml.org/blog/opam-2-0-beta/
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.