Here is the latest OCaml Weekly News, for the week of February 24 to March 03, 2015.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-02/msg00153.htmlJordan W announced:
I'm cross posting my post from the opam-devel list: Since there is a lot of interest in OCaml from web frontend communities, I thought it would be useful to imagine what the ideal development flow for this audience would look like. I know there's a ton of progress being made on documentation, and build systems, but I thought I would explore the problem from the perspective of a frontend developer, which means starting with the tooling that they are familiar with. One common tool is `CommonJS/package.json`, which is a way to model and organize dependencies using a single JSON file per package. The npm command line tools allow you to install files to disk based purely on these package.json files. I created a proof of concept called CommonML, which lets developers use their familiar CommonJS workflow with OCaml: https://github.com/jordwalke/CommonML I also took used it as an opportunity to explore what can be done when there are opinionated conventions in place. If you have a predictable project structure, how can that benefit us? In this case, I created an automatic docs builder (with nice styling) and also automatically generate IDE autocomplete support for all your dependencies (and your project's internal modules). I hope there is at least something we can take away from it that helps inform the design of OPAM and related tools. One nice aspect is that with `CommonJS`, there needn't be an authoritative package service. Your package.json file can point to arbitrary git URLs if you like. (Note: The npm command line tool is *not* the npm package service - they are made by the same organization but one may be used without the other). However, this prototype I've built does allow you to host OCaml code on npm and depend on it. By far the nicest thing about developing with `CommonJS` is that you don't have to think about module namespace collisions. There is Just One Way to namespace modules/packages. This prototype automatically sets up a similar namespacing convention for OCaml modules. It's not flexible, and you can't customize it, but it always works. It uses module aliases (thank you to Leo White for helping me come up with the build conventions). Another thing I like about the `CommonJS` workflow is that developing packages locally is virtually the same as developing against remote dependencies. (`npm link` is much like `opam pin` I'm told). When you `npm install` dependencies, everything is pulled down into a local sandbox(node_modules directory) instead of being installed globally by default. If you want to see what versions your local package is seeing, just traverse the file system! If you want to reinstall, just delete the node_modules directory and then `npm install` again. I believe there is a way to get it to use a global package cache so the node_modules might contain symlinks to those shared packages - but that's just an optimization. There isn't any notion of building in `npm`, so there wouldn't be a build cache I believe. In my quick prototype, every dependency must be compiled at least once for the root level project that you are building. This ends up being nice in cases where the build flags (such as -g) must be in effect for the compilation of all my dependencies - relying on the build flags that you *installed* the package with will bite you. But of course, the rebuilding approach can end up being super slow. Still, the incremental build times are *totally* reasonable since it does try to do some basic incremental compilation. I would have used ocamlbuild which probably does a much better job, but I needed to write my own totally custom operations in order to get the auto-namespacing (with the help of Leo White). I wasn't sure how to do that with ocamlbuild, but if I could, I imagine the incremental compilation times would be way better. Either way, for most of the work I do (developing libraries with many other small libraries as dependencies) - I could see a development flow like this being a worthwhile goal, especially if it makes OCaml much more comfortable for a *huge* set of developers. `CommonJS` is likely becoming the most popular development flow. It's just a hacky proof of concept, but it was fun.Andrew Herron then asked and Jordan W replied:
> I've been thinking about this a bit, as a JS developer who is experimenting > with OCaml (in my non-existant free time). I don't use the CommonJS flow in > my day job although we do have many projects which our internal > build/dependency system combines with similar results. > >> I created a proof of concept called CommonML, which lets developers use >> their familiar CommonJS workflow with OCaml: >> https://github.com/jordwalke/CommonML > > My initial thoughts were to stick with the OPAM repositories; even if I have > to make a local OPAM repo server it seems like leveraging the existing > ecosystem is a good idea. My experiments use a dedicated `opam switch` for > the project, enforced by the Makefile (which might not scale to multiple > projects, but I haven't tried that yet). > > I can think of one good reason to share OCaml and JS dependencies on the > same server though, and that's including a JS library in a js_of_ocaml > project. Certainly using a single package.json file to specify both JS and > OCaml dependencies is an interesting idea (even if under the hood we > eventually find a way to use OPAM for the OCaml projects). There's certainly a lot of ideas/experiments in CommonML all rolled into one. The overarching goal was to just explore the ideal developer flow for people who are either used to CommonJS or who appreciate a highly sandboxed development model without globals. There's some "pointless" goodies thrown in like zero effort merlin support and automatic doc generation (which is now being solved in a *much* better way by other people more knowledgeable than myself). CommonML is just a hacky script, but I find it useful to build developer tools by starting with the ideal end developer experience and performing whatever atrocious hacks I have to in order to create it. After I get feedback, I can explore doing it the right way. Obviously OPAM is the real deal, and I hope some people can help me achieve much of this with OPAM (as it is, or in future versions). But the most valuable part of the CommonML experiment, actually has nothing to do with package managers/sandboxes at all - it's the automatic namespacing of dependencies (using module aliases) and automatic generation of merlin completion files. You literally only have to list a new dependency in your `package.json`, then it will resolve all naming conflicts, build correctly, and allow you to immediately start autocompleting using merlin. I suspect such a seamless experience is only feasible when there are opinionated conventions in place. I feel like most people would be satisfied with the ones explored in CommonML: - namespaced dependencies, non-namespaced internal modules (ModuleInsideMyPackage.x, YourPackage.ModuleInsideYourPackage.y) - powered by module aliases. - "exports" field in `package.json` that determines which modules should be publicly available to other packages that depend on you (nothing is visible to other packages by default). I don't know enough about the OCaml build toolchain to solve this in a scalable way so I made it work generally enough for a couple of the projects that I'm prototyping. I hope the same can be achieved in some other more sophisticated build tool. Has anyone seen anything like the automatic namespacing I've prototyped here? I couldn't imagine developing without it, personally.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-02/msg00163.htmlDeep in this thread, David Allsopp asked and Gabriel Scherer replied:
> is there (in theory) a relatively easy kind of annotation which > could be added to type 'a t in a signature which would tell the > compiler that 'a t and 'b are equal and compatible iff 'a and 'b > are equal/compatible but still remain abstract? Yes, this is exactly the point of "injectivity" which has been discussed at length in http://caml.inria.fr/mantis/view.php?id=5985 and summarized in a (rather difficult to follow for the non-expert) talk by Jacques Garrigue at the OCaml Meeting 2013 in Boston, abstract: http://www.math.nagoya-u.ac.jp/~garrigue/papers/injectivity.pdf slides: https://ocaml.org/meetings/ocaml/2013/slides/garrigue.pdf It would not be difficult to teach the type-checker about injectivity, but there is no concrete syntax in the language to discuss it, and it is not easy to design a good one (which is why it has not been added yet). The difficult question is whether users should add an extra mark to explicitly require injectivity (like we do for covariance for example), or whether it should be assumed when using the default (type 'a t) notation, with an explicit mark to allow *non*-injectivity.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-02/msg00172.htmlGerd Stolpmann announced:
just released ocamlnet-4.0.2, with some bug fixes (one important). Note that I had to change the type of Uq_engines.engine (new method request_proxy_notification). If you define your own engines, this may break your builds. Most users won't be affected by this, though. Download, changelog and other links under http://projects.camlcity.org/projects/ocamlnet.html
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-02/msg00176.htmlJeremy Yallop announced:
Higher-order, Typed, Inferred, Strict: ACM SIGPLAN ML Family Workshop Thursday September 3, 2015, Vancouver, Canada (immediately following ICFP and preceding OCaml Users and Developers Workshop) Call for papers: http://www.mlworkshop.org/ml2015/ ML is a very large family of programming languages that includes Standard ML, OCaml, F#, SML#, Manticore, MetaOCaml, JoCaml, Alice ML, Dependent ML, Flow Caml, and many others. All ML languages share several fundamental traits, besides a good deal of syntax. They are higher-order, strict, mostly pure, and typed, with algebraic and other data types. Their type systems are derived from Hindley-Milner. The development of these languages has inspired a significant body of computer science research and influenced the design of many other programming languages, including Haskell, Scala and Clojure, Rust, ATS and many others. ML workshops have been held in affiliation with ICFP continuously since 2005. This workshop specifically aims to recognise the entire extended ML family and to provide a forum for presenting and discussing common issues, both practical (compilation techniques, implementations of concurrency and parallelism, programming for the Web) and theoretical (fancy types, module systems, metaprogramming). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Scala, Rust, Nemerle, ATS, etc.), to exchange experience of further developing ML ideas. The ML family workshop will be held in close coordination with the OCaml Users and Developers Workshop. Scope ----- We acknowledge the whole breadth of the ML family and aim to include languages that are closely related (although not by blood), such as Rust, ATS, Scala, and Typed Clojure. Those languages have implemented and investigated run-time and type system choices that may be worth considering for OCaml, F# and other ML languages. We also hope that the exposure to the state of the art ML might favourably influence those related languages. Specifically, we seek research presentations on topics including (but not limited to) * Language design: abstraction, higher forms of polymorphism, concurrency, distribution and mobility, staging, extensions for semi-structured data, generic programming, object systems, etc. * Implementation: compilers, interpreters, type checkers, partial evaluators, runtime systems, garbage collectors, foreign function interfaces, etc. * Type systems: inference, effects, modules, contracts, specifications and assertions, dynamic typing, error reporting, etc. * Applications: case studies, experience reports, pearls, etc. * Environments: libraries, tools, editors, debuggers, cross-language interoperability, functional data structures, etc. * Semantics: operational and denotational semantics, program equivalence, parametricity, mechanization, etc. Four kinds of submissions will be accepted: Research Presentations, Experience Reports, Demos and Informed Positions. * Research Presentations: Research presentations should describe new ideas, experimental results, or significant advances in ML-related projects. We especially encourage presentations that describe work in progress, that outline a future research agenda, or that encourage lively discussion. These presentations should be structured in a way which can be, at least in part, of interest to (advanced) users. * Experience Reports: Users are invited to submit Experience Reports about their use of ML and related languages. These presentations do not need to contain original research but they should tell an interesting story to researchers or other advanced users, such as an innovative or unexpected use of advanced features or a description of the challenges they are facing or attempting to solve. * Demos: Live demonstrations or short tutorials should show new developments, interesting prototypes, or work in progress, in the form of tools, libraries, or applications built on or related to ML and related languages. (You will need to provide all the hardware and software required for your demo; the workshop organisers are only able to provide a projector.) * Informed Positions: A justified argument for or against a language feature. The argument must be substantiated, either theoretically (e.g. by a demonstration of (un)soundness, an inference algorithm, a complexity analysis), empirically or by substantial experience. Personal experience is accepted as justification so long as it is extensive and illustrated with concrete examples. Format ------ The ML 2015 workshop will continue the informal approach used since 2010. Presentations are selected from submitted abstracts. There are no published proceedings, so contributions may be submitted for publication elsewhere. We hope that this format will encourage the presentation of exciting (if unpolished) research and deliver a lively workshop atmosphere. Each presentation should take 20-25 minutes, except demos, which should take 10-15 minutes. The exact time will be decided based on the number of accepted submissions. The presentations will likely be recorded. Post-proceedings ---------------- ML 2015 is an informal workshop without proceedings. We are planning to publish a post-proceedings and to invite interested authors of selected presentations to expand their abstracts for inclusion. Coordination with the OCaml Users and Developers Workshop --------------------------------------------------------- The OCaml workshop is seen as more practical and is dedicated in significant part to OCaml community building and the development of the OCaml system. In contrast, the ML family workshop is not focused on any language in particular, is more research-oriented, and deals with general issues of ML-style programming and type systems. Yet there is an overlap, which we are keen to explore in various ways. The authors who feel their submission fits both workshops are encouraged to mention it at submission time or contact the Programme Chairs. Submission details ------------------ Submissions should be at most two pages, in PDF format, and printable on US Letter or A4 sized paper. A submission should have a synopsis (2-3 lines) and a body between 1 and 2 pages, in one- or two-column layout. The synopsis should be suitable for inclusion in the workshop programme. Submissions must be uploaded to the workshop submission website before the submission deadline (Monday 18th May, 2015). If you have a question concerning the scope of the workshop or the submission process, please contact the programme chair. Important dates --------------- Monday 18th May (any time zone) Abstract submission deadline Monday 29th June Author notification Thursday 3rd September 2015 ML Family Workshop Programme committee ------------------- Damien Doligez (Inria Paris-Rocquencourt, France) Suresh Jagannathan (Purdue University, USA) Patricia Johann (Appalachian State University, USA) Sam Lindley (University of Edinburgh, UK) Moe Masuko (Ochanomizu University, Japan) Adriaan Moors (Typesafe, USA) Scott Owens (University of Kent, UK) Jonathan Protzenko (Microsoft Research, USA) Martin Sulzmann (Karlsruhe University of Applied Sciences, Germany) Jeremy Yallop (University of Cambridge, UK) (PC chair)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-02/msg00178.htmlLeonardo Laguna Ruiz asked:
I’m working on a library which wraps functions and clases written in C++. I’m trying to setup a build system based in oasis but I haven’t found any example on how to do it. So far I have been able of compiling my test programs using cmake and ocamlbuild. I use cmake to generate a static library out of my C++ file. Then I call ocamlbuild (from cmake) to generate a object file from my main file (main.native.o). Finally I link everything using cmake. I have tried to link the my test program with ocambuild by passing all the necessary flags (use stdlib=libc++ and link CoreFoundation and IOKit in OS X) but I haven’t succeeded using ocamlbuild (or oasis). Does anyone has an example on how to build a library that uses C++ code?Ivan Gotovchits replied:
In BAP project we're building C++ bindings with oasis+ocamlbuild. Look at `cxx_rule` in `myocamlbuild.ml.in` file, definitions like `cxx` and `cxx_flags` in `setup.ml.in` and, of course, `_oasis` Feel free to ask any questions, Regards, Ivan : https://github.com/BinaryAnalysisPlatform/bapMartin DeMello also replied:
Not my project, but looks interesting: https://github.com/JoeDralliam/Ocsfmlygrek also replied and Peter Zotov added:
> Here is one - > http://stackoverflow.com/questions/21728826/building-c-code-with-ocamlbuild I submitted an issue to make it better: http://caml.inria.fr/mantis/view.php?id=6798Shayne Fletcher also replied:
This blog post may be of use http://shayne-fletcher.blogspot.com/2014/02/extending-ocaml-in-c-boostdate-time.html.
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/. Part 2: Running your own DNS Resolver with MirageOS: http://hh360.user.srcf.net/blog/2015/03/part-2-running-your-own-dns-resolver-with-mirageos/ Senior Software Engineer at McGraw-Hill Education (Full-time): http://functionaljobs.com/jobs/8787-senior-software-engineer-at-mcgraw-hill-education
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.