Hello
Here is the latest OCaml Weekly News, for the week of December 01 to 08, 2015.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-12/msg00003.html
Gabriel Scherer announced:We are going to move the OCamlbuild build system outside the standard compiler distribution in the next few months. This has been demanded by a part of the OCamlbuild user community for a long time¹, hoping to lower the barrier to contribution and have a more flexible release schedule. The switch should happen in the following months, with the goal of being done before the release of the next OCaml version (4.03), planned for the first quarter of 2016. We have not planned all the details yet, and there is still time for giving your advice on how best to proceed. ¹: PR#6402: Move ocamlbuild to its own repository Hugo Heuzard, 2014-05-07 http://caml.inria.fr/mantis/view.php?id=6402 # Impact on users (maintainers of ocamlbuild-using software) The impact on the users should be minimal. The only difference is that you cannot assume anymore than *any* OCaml installation has ocamlbuild available. Projects using ocamlbuild as their build system (directly or through OASIS) should have it marked as an explicit compile-time dependency in their packaging descriptions. For this purpose, I have created an "ocamlbuild" package in the main OPAM repository, that for now is just a dummy package (for OCaml < 4.03, it does not need to actually install anything). You can already start adding "ocamlbuild" as a dependency in the OPAM metadata² in your development repositories (the one used by "opam pin"), and in future uploads to the public opam repository. For existing packages in the public opam repository, there is nothing to do. We have used an automated transform³ to add this new dependency to all packages that use ocamlbuild⁴, so that no change on already-published packages should be necessary. The scripts used to do so is publicly available⁵, so maintainers of other opam repositories should be able to run it as well (please contact me if you have any trouble doing so). ²: just edit your OPAM file to change depends: [ ... ] into depends: [ ... "ocamlbuild" {build} ] ³: https://github.com/ocaml/opam-repository/pull/5140 ⁴: the heuristic used is to assume that a package uses ocamlbuild if: - it contains a _tags or myocamlbuild.ml file somewhere, or - it calls "ocamlbuild" from OPAM's build steps, or - it has an _oasis file which specifies ocamlbuild as build system 2885 of the 4214 packages in the current opam-repository master trigger this heuristic. If you happened to know of a project that uses ocamlbuild despite failing this test, please let us know so that we can refine the bulk-update script. ⁵: https://github.com/gasche/opam/blob/ocamlbuild-migration-script/admin-scripts/add_ocamlbuild_dependency.ml One notable exception would be authors of ocamlbuild plugins. The bulk update script only adds ocamlbuild as a build-time dependency; if you provide libraries on top of OCamlbuild's libraries, you may need a manual update of existing opam metadata. Could you please let me know about it, in case there is an easy way to update the migration script? # Impact on project development OCamlbuild's main strength is being able to build simple OCaml projects in an extremely simple way -- yet scale when they grow a bit in complexity. It makes it useful to many OCaml users, and thus a rather rewarding project to contribute to. In the past few years it has had a relatively calm development rate, with no ground-breaking changes, but rather small added features or usability improvements, and the occasional bugfixes. It is also wide open to external contributions; the 32 changes since the beginning of the 4.02 lifetime have been contributed by 18 different people. I have been the main regular contributor to OCamlbuild's development in the last few releases of OCaml (with various much-appreciated external contributions), and I plan to continue improving the tool at a reasonable pace. Some people have requested that ocamlbuild be split off in the past, arguing that it would increase the contributor base -- we will see if it indeed lowers the barrier to contribution. Last but not least, whitequark, who has done many useful contributions in the past releases, seems willing to help supporting the project. Until fairly recently, the most lamented defect of OCamlbuild was a lack of documentation. I announced a new manual⁶ this year, and am planning to make it the default manual with the next ocamlbuild release. Contributions to the manual are warmly welcome; Christian Linding has contributed a lot of useful feedback and started filling a directory of small, representative examples⁷; you should feel free to add one for your preferred distinct use-case. ⁶: https://github.com/gasche/manual-ocamlbuild/blob/master/manual.md ⁷: https://github.com/gasche/manual-ocamlbuild/tree/master/examples The new development repository of OCamlbuild should be hosted by the OCaml Github organization, at https://github.com/ocaml/ocamlbuild Have fun hacking (and building) OCaml software!
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-12/msg00019.html
Daniel Bünzli announced:I'd like to announce the first release of Logs. Here's the blurb: Logs provides a logging infrastructure for OCaml. Logging is performed on sources whose reporting level can be set independently. Log message report is decoupled from logging and is handled by a reporter. A few optional log reporters are distributed with the base library and the API easily allows to implement your own. Logs depends only on the `result` compatibility package. The optional `Logs_stdo` reporter on standard outputs depends on Fmt. The optional `Logs_browser` reporter that reports to the web browser console depends on js_of_ocaml. The optional `Logs_cli` library that provides command line support for controlling Logs depends on `Cmdliner`. Logs and its reporters are distributed under the BSD3 license. Feedback on the API is welcome, it could still change a bit before stabilizing on a 1.0.0 release. Homepage: http://erratique.ch/software/logs API docs: http://erratique.ch/software/logs/doc The continuation based formatting trick used by Logs for minimizing non-logging overhead is based on Jeremy Yallop's findings; Gabriel Radanne helped to make further tests. Thanks to them and see [1] for the full discussion. Best, Daniel [1] https://github.com/mirage/ocaml-git/pull/130#issue-111278246Malcolm Matalka and Daniel Bünzli then had the following conversation:
Malcom: > I poked around the documentation a bit but I wasn't quite clear on if > Logs provides a synchronous or asynchronous API. Daniel: > That's up to the reporter you install to decide. Daniel: > More precisely, as you can see here [1] it is in charge of invoking the > continuation. > > [1] http://erratique.ch/software/logs/doc/Logs.html#TYPEreporter Malcom: > That seems quite nice, thanks. Daniel: > But it should be added that it may be problematic if you want the > synchronous semantics and you are using lwt. > > See https://github.com/dbuenzli/logs/issues/5
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-12/msg00033.html
Nate Foster announced:I thought folks might enjoy hearing a new OCaml and Jane Street Async themed song by MC FloCaml (also known as Jared Wong), as performed in the final lecture of Michael Clarkson's CS 3110 class this semester at Cornell. Enjoy, -N Video (by Neel Kapse): http://www.cs.cornell.edu/~jnfoster/flocaml.mp4 Music (by Jared Wong): https://soundcloud.com/rangersbeats/flocaml Lyrics: Take big steps to eval, like a nomad Bind and return like a Monad Got you looking so mad about the signature I got you using in the directory with the MLI files the compiler was choosing The type checks out, I’m feeling greater Defer the value now and I return a little later Cuz I’m threaded, so for now I ain’t got much to say I put a semicolon on to throw the unit away At this point, I only know what you know that we know I fill up the Monad like it’s a burrito And I read it, I’m never defeated, bind and retrieve it with anonymous functions, so that I’m never gonna leave it behind And don’t worry, in case you haven’t heard I’m bout to Ivar.read it and put it up in a deferred Or I could ref it and bang it for an immutable copy And just a little later, you can call me A$YNC ROCKY Try to stop me, I wouldn’t care, I’d be ambivalent It’s the same game, behavioral equivalence And I don’t even think that you was all that Your scheduler was so lonely it couldn’t ever get a callback And really that’s the kind of thing that you couldn’t handle Because my double semicolons got them screaming OH CAML Side effects, catch them all, now you know we got ‘em All up in UTOP but I started on the bottom So please take a second and just listen (listen) Up in your speakers I’m wishin to write a weaker precondition Took a few small steps, I was feeling like a dope Now I’m up in OCaml, we using lexical scope But once again I need to try to understand this, All these pedantic antics tripping up my semantics I can stress, how much I really want to do it all But once it’s said I can’t take it back it’s immutable And there was only one course plan Turning twenty-one, going on 3110 But really, at this moment, I’m still living in terror Because the type checker be giving me compile time errors The C A M L, with an O at the front It’s not imperative scaring ya, and we ain’t tryna stunt Just tryna process every single type to keep it in check And having higher-order fun with it is just a side effect
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-12/msg00035.html
Lindsey Kuper announced:ICFP 2016 The 21st ACM SIGPLAN International Conference on Functional Programming http://conf.researchr.org/home/icfp-2016 Call for Papers Important dates --------------- Submissions due: Wednesday, March 16 2016, 15:00 (UTC) https://icfp2016.hotcrp.com (in preparation as of December 1) Author response: Monday, 2 May, 2016, 15:00 (UTC) - Thursday, 5 May, 2016, 15:00 (UTC) Notification: Friday, 20 May, 2016 Final copy due: TBA Early registration: TBA Conference: Tuesday, 20 September - Thursday, 22 September, 2016 Scope ----- ICFP 2016 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): - Language Design: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. - Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. - Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling. - Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types. - Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. - Applications: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia and 3D graphics programming; scripting; system administration; security. - Education: teaching introductory programming; parallel programming; mathematical proof; algebra. - Functional Pearls: elegant, instructive, and fun essays on functional programming. - Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working. If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ------------------------------------ - By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at most 12 pages (6 pages for an Experience Report), in standard SIGPLAN conference format, including figures but ***excluding bibliography***. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. ***ICFP 2016 will employ a lightweight double-blind reviewing process.*** To facilitate this, submitted papers must adhere to two rules: 1. ***author names and institutions must be omitted***, and 2. ***references to authors' own related work should be in the third person*** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the PC and external reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. We have put together a document answering frequently asked questions that should address many common concerns: http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#Submission-and-Reviewing-FAQ - Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of your paper and learned your identity. - Each submission must adhere to SIGPLAN's republication policy, as explained on the web at: http://www.sigplan.org/Resources/Policies/Republication - Authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are given below. Presentations will be videotaped and released online if the presenter consents. The proceedings will be freely available for download from the ACM Digital Library from at least one week before the start of the conference until two weeks after the conference. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard SIGPLAN conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available at http://www.sigplan.org/Resources/Author/ Submission: Submissions will be accepted at https://icfp2016.hotcrp.com (in preparation as of December 1). Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 72-hour period, starting at 15:00 UTC on Monday, 2 May, 2016, to read reviews and respond to them. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking the definitive version of ACM article should reduce user confusion over article versioning. After your article has been published and assigned to your ACM Author Profile page, please visit http://www.acm.org/publications/acm-author-izer-service to learn how to create your links for free downloads from the ACM DL. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Special categories of papers ---------------------------- In addition to research papers, ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to six pages. Authors submitting such papers may wish to consider the following advice. Functional Pearls ================= A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: - a new and thought-provoking way of looking at an old idea - an instructive example of program calculation or proof - a nifty presentation of an old or new data structure - an interesting application of functional programming techniques - a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission you wish to have treated as a pearl must be marked as such on the submission web page, and should contain the words ``Functional Pearl'' somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. Experience Reports ================== The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works -- or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: - insights gained from real-world projects using functional programming - comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum - project-management, business, or legal issues encountered when using functional programming in a real-world project - curricular issues encountered when using functional programming in education - real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal ICFP paper by its title, by its length, and by the criteria used to evaluate it. - Both in the proceedings and in any citations, the title of each accepted Experience Report must begin with the words ``Experience Report'' followed by a colon. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. - An Experience Report is at most six pages long. Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. - Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The program committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: make a claim about how well functional programming worked on your project and why, and produce evidence to substantiate your claim. If functional programming worked for you in the same ways it has worked for others, you need only to summarize the results?the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterize your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. If your paper not only describes experience but also presents new technical results, or if your experience refutes cherished beliefs of the functional-programming community, you may be better off submitting it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. If you are unsure in which category to submit, the program chair will be happy to help you decide. Organizers ---------- General Co-Chairs: Jacques Garrigue (Nagoya University) Gabriele Keller (University of New South Wales) Program Chair: Eijiro Sumii (Tohoku University) Program Committee: Koen Claessen (Chalmers University of Technology) Joshua Dunfield (University of British Columbia, Canada) Matthew Fluet (Rochester Institute of Technology) Nate Foster (Cornell University) Dan Grossman (University of Washington, USA) Jurriaan Hage (Utrecht University) Roman Leshchinskiy (Standard Chartered Bank) Keisuke Nakano (The University of Electro-Communications) Aleksandar Nanevski (IMDEA Software Institute) Scott Owens (University of Kent) Sungwoo Park (Pohang University of Science and Technology) Amr Sabry (Indiana University) Tom Schrijvers (KU Leuven) Olin Shivers (Northeastern University) Walid Taha (Halmstad University) Dimitrios Vytiniotis (Microsoft Research, Cambridge) David Walker (Princeton University) Nobuko Yoshida (Imperial College London, UK) External Review Committee to be announced.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-12/msg00042.html
Gerd Stolpmann announced:there is a new version of findlib for download. The main difference of findlib-1.6.1 is that the style for specifying plugins changed. Now, use something like plugin(byte) = "archive.cma" plugin(native) = "archive.cmxs" (instead of archive(byte,plugin) and archive(native,plugin). This change comes together with a dynamic loader: Fl_dynload. Just call it like Fl_dynload [ "pkg1"; "pkg2" ] to load these two packages together with any predecessors into the running executable. (But see also the comments on the reference page: http://projects.camlcity.org/projects/dl/findlib-1.6.1/doc/ref-html/lib/Fl_dynload.html) Note that the old style is also understood, but users are strongly encouraged to switch to the new style with the plugin variable. The reason is that the old style is broken in one respect: if there is no plugin definition at all, findlib would take the cmxa archive instead, which can never work. This feature was mainly contributed by François Bobot. A few other changes: - new "ocamlfind lint" command for checking META files (also from François Bobot) - new %m format for "ocamlfind query" to get the location of the META file (me) - new: ocamlfind printconf metapath (me) - some fixes for Windows (MSYS_NT, spaces in paths) (Christophe Troestler) The project page is still at http://projects.camlcity.org/projects/findlib.htmlGerd Stolpmann then added:
> Fl_dynload [ "pkg1"; "pkg2" ] Correction: this should read Fl_dynload.load_packages [ "pkg1"; "pkg2" ]
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-12/msg00045.html
William Le Ferrand announced:I've recently started to work on a tool that aims at making the planning and the execution of real-world activities a little less tedious, and sharing the learnt experience a little bit easier. The idea is to capture the outline of a social activity into a playbook, a graphical+code representation of the different stages of the activity and the transitions between those stages, eg [1]. Those playbooks can then be shared, forked & improved,and executed by a runtime that attempts to move from stage to stage automatically and asks for manual input when it can't. I've pushed to [2] a simple ocsigen app that provides - an API to write playbooks, with helpers to use emails to trigger events & react to people's inputs, define cron tasks, etc - a sandbox that can be used to run a playbook step by step and observe its behavior - an executor capable of running a playbook for real users using an email server It is a very early implementation, definitely not a turn-key product, but I'm already using it to organize recurring dinners for a group of parents, as well as some children activities (it's deployed at [3]). My goal with this project is to build a library of effective playbooks for a wide range of activities, share what I learnt while setting up these activities and learn from other people's experiences. This post is already way too long but if some of you are interested in learning more about the project, make suggestions and/or contribute to it, please get in touch. As usual, a big thanks to the ocsigen team & the ocaml community for all these amazing tools! william [1] https://github.com/accretio/accretio/blob/master/playbooks/demo.ml [2] https://github.com/accretio/accretio [3] https://accret.io
Here is a sneak peek at some potential future features of the Ocaml compiler, discussed by their implementers in these Github Pull Requests. Do path compression, and undo it in case of unification error https://github.com/ocaml/ocaml/pull/294 GC latency improvements https://github.com/ocaml/ocaml/pull/297 Add ocaml manuals in the repository https://github.com/ocaml/ocaml/pull/302 Document types.mli and typedtree.mli https://github.com/ocaml/ocaml/pull/310 Revert user defined indexing operators https://github.com/ocaml/ocaml/pull/320
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/. Andrej Bauer: Postdoc position in Ljubljana http://math.andrej.com/2015/12/07/postdoc-position-in-ljubljana/ Github OCaml jobs: Full Time: Software Developer (Functional Programming) at Jane Street in New York, NY; London, UK; Hong Kong http://jobs.github.com/positions/0a9333c4-71da-11e0-9ac7-692793c00b45 Jane Street: Testing with expectations https://blogs.janestreet.com/testing-with-expectations/ Functional Jobs: Haskell Engineer at Wagon (Full-time) https://functionaljobs.com/jobs/8868-haskell-engineer-at-wagon
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.