Here is the latest OCaml Weekly News, for the week of May 05 to 12, 2015.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-05/msg00032.htmlDeep in this thread, Oleg Kiselyov said and Jeremy Yallop replied:
> Of course MetaOCaml serialization can be improved. What I'd like to > stress is that you don't have to wait for the improvement. You can > always, instead of > .<fun u -> x>. > write > .<fun u -> .~(mylift x)>. > where > mylift : t -> t code > is *your* function that does whatever _you_ like it to do at that > particular type t (it should still produce something of the type (t > code)). > > If some particular mylift functions turn out popular, they can be > added to MetaOCaml, to save everyone trouble writing them. > > And I generally agree with Leo that this implicit lifting is > baroque. At present I'm not sure if requiring the explicit lifting is > too much of a burden. I'm sure that with modular implicits, it won't > be. I've just pushed an OPAM switch for an OCaml compiler that combines the MetaOCaml and modular implicits patches, making it possible to experiment with explicit user-defined polymorphic CSP. For example, you might define a signature, CSP, for "things that can be persisted": module type CSP = sig type t val lift : t -> t code end together with a top-level function that dispatches to the appropriate instance let csp (implicit C: CSP) (x : C.t) = C.lift x and instances of CSP for each type of interest. Here's an instance for the stx type from earlier in the thread: implicit module CSP_stx : CSP with type t = stx = struct type t = stx let rec lift : stx -> stx code = function | A -> .< A >. | B s -> .< B .~ (lift s) >. | C (s1, s2) -> .< C ( .~(lift s1), .~(lift s2) ) >. end and here's a parameterised instance for lists that makes it possible to persist lists of any persistable element type: implicit functor CSP_list(C: CSP) : CSP with type t = C.t list = struct type t = C.t list let rec lift : C.t list -> C.t list code = function  -> .<  >. | x :: xs -> .< .~(csp x) :: .~(lift xs) >. end These two instances make it possible to use the CSP function to persist stx values, or lists of stx values, or lists of lists of stx values (etc.): # let ba = B A in .< .~(csp ba) >.;; - : stx code = .<Stx.B Stx.A>. # let l = [A; B A] in .< .~(csp l) >.;; - : stx list code = .<[Stx.A; Stx.B Stx.A]>. # let ll = [[A; B A]] and ba = B A in .< .~(csp ll), .~(csp ba) >.;; - : (stx list list * stx) code = .<([[Stx.A; Stx.B Stx.A]], (Stx.B Stx.A))>. It's easy to imagine having the csp function built in to MetaOCaml, so that we could write .< x >. (or some similarly convenient syntax) to mean .< .~(csp x) >... You can try out the switch with OPAM in the usual way: opam update opam switch 4.02.1+modular-implicits-ber eval `opam config env`
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-05/msg00034.htmlDamien Doligez announced:
We are now preparing release 4.02.2, mostly a bug-fix release with a few new features. We are planning to release it in the first week of June (about 1 month from now). If you want to try a preview, get it: - from github: < https://github.com/ocaml/ocaml/tree/4.02 > (don't forget to switch to branch 4.02 after cloning) - through OPAM: opam switch 4.02.0+trunk (watch out for the misnomer) If you find bugs, please report them as quickly as possible. As for the next major release, it will include a number of new features (including, if all goes well, support for multicore). It will be released some time around the end of this year. -- Damien Doligez for the OCaml development teamFrancois Berenger then asked and Mark Shinwell replied:
> Who added the support for multicore? > > Will it have an impact on the performance of sequential programs (i.e. which > don't use multicore)? > > Does it mean we will be able to write parallel code that scales better > than what we currently can get with parmap? > I.e. we could see a speedup even if the task is very fine grain. > > Will we have to rewrite Parmap ? ;) I can answer two of your points: I think it's unlikely that multicore support is going to be in a production-ready state for 4.03, although I may be proven wrong. It seems plausible that a beta version of the support will be ready at that time, however. Degradation of the performance of code not using the new parallelism features (but possibly using the existing thread support) is a matter of serious concern for some users, and best efforts will be made to minimize or eliminate it. We will know more on this front in the next few months.Mark Shinwell later added:
Sorry, I missed one paragraph: the multicore support is being developed at OCaml Labs in Cambridge, UK.
Archive: http://lists.ocaml.org/pipermail/teaching/2015-May/000070.htmlOn the Teaching mailing list, Yann Salmon asked and Gabriel Scherer replied:
> I have recently started using Arthur Charguéraud's experimental OCaml > compiler and top-level with improved type error messages. This is great > and the students are now able to gain better autonomy in programming. I > modified the OCaml source code to enable easy-type-errors by default. > > However, Arthur's patch cannot improve runtime error messages, like the > frequent Out-of-bound access exception. For this, I would like the OCaml > toplevel to automatically print a backtrace. > > I understand that I should do two things : > 1. compile the toplevel with -g > 2. run the toplevel with OCAMLRUNPARAM set to B. > > I do not understand however what I should change in the makefiles to > pass the -g option correctly (my attempts were not successful), and I am > not sure what parts of the OCaml source code I should change to get de > backtrace printing behaviour enabled by default. > > Can somebody help ? I don't think you need the toplevel itself to be compiled with -g to get stack traces (that would be true of stack traces raised by exception inside the toplevel implementation, but those correspond to OCaml implementation bugs, not to bugs in your student's programs). However, in existing released versions of OCaml I suspect that stack traces are not available for code defined from the toplevel (I think it works for libraries compiled outside the toplevel and linked/loaded from the toplevel, but not for functions defined directly by sending phrases to the toplevel). This was the topic of the issue report PR#6468 ( http://caml.inria.fr/mantis/view.php?id=6468 ), and Peter Zotov developed a patch to implement that feature. It will be available in the next *major* release of the OCaml distribution (around autumn/winter), but if you already maintain a fork you could try to backport it.
Thanks to Alp Mestan, we now include in the OCaml Weekly News the links to the recent posts from the ocamlcore planet blog at http://planet.ocaml.org/. Full Time: Senior C++ Engineer at Ufora in New York, NY: http://jobs.github.com/positions/0bbe858e-f55f-11e4-98b7-491295bfdc93 OPAM 1.2.2 Released: http://ocaml.org/ Haskell Web Engineer at Front Row Education (Full-time): http://functionaljobs.com/jobs/8823-haskell-web-engineer-at-front-row-education Full-Stack Senior Functional Web Engineer at Front Row Education (Full-time): http://functionaljobs.com/jobs/8823-full-stack-senior-functional-web-engineer-at-front-row-education CPU Registers and OCaml: https://blogs.janestreet.com/cpu-registers-and-ocaml-2/ Permutations: http://typeocaml.com/2015/05/05/permutation/
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.