Here is the latest OCaml Weekly News, for the week of November 29 to December 06, 2016.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00112.htmlmoosotc announced:
New version of llpp (tagged v25) is now available at: * http://repo.or.cz/w/llpp.git (has "tutorial" videos) * https://github.com/moosotc/llpp/ (has a bug tracker) ============================================================================ Changes (relative to v23) * improved keyboard link navigation * custom key mappings are shown in the help screen * build.sh script should work again (بفضل طارق) * bugfixes * synced with mupdf 1.10a * reworked handling of keyboard events (pp.sed is gone and porting to other windowing systems should be much simpler now) ============================================================================ Summary v23..v25 67 malc Diffstat v23..v25 BUILDING | 2 +- Shakefile.hs | 83 +- Thanks | 1 + build.sh | 5 +- config.ml | 1474 ++++++------ keys.ml | 7 + link.c | 264 +-- main.ml | 7449 +++++++++++++++++++++++++++++----------------------------- misc/dllpp | 2 + parser.ml | 220 +- pp.sed | 86 - todo.org | 15 +- utils.ml | 50 +- wsi.ml | 1234 +++++----- wsi.mli | 50 +- 15 files changed, 5498 insertions(+), 5444 deletions(-)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00113.htmlAlain Frisch announced:
You might be interested in the ocaml-vdom project which has been used by LexiFi for some time and open-sourced recently. It contains two components which we use to create our browser-side UIs with js_of_ocaml and which might be useful to the community: - Bindings to the DOM and other browser APIs, implemented with gen_js_api. (Partial bindings, expanded on demand.) - An implementation of a "virtual DOM" and the "Elm architecture", i.e. a programming model where the UI is specified by a state type, a view function (producing a functional version of the DOM), and an update function that modifies the state based on messages (generated by UI events or external interactions). Project page: https://github.com/LexiFi/ocaml-vdomYaron Minsky and Alain Frisch then discussed:
> Any tips on setting up a project? For example, with elm I use > elm-webpack-starter [https://github.com/moarwick/elm-webpack-starter], > which sets up an asset pipeline and a dev environment with live reloading. I've added a simple "Usage" section to the project's README. But don't expect (yet) a rich ecosystem around the project!Vincent Balat asked and Alain Frisch replied:
> How would you compare the virtual DOM with a functional reactive > interface, as you can do with Tyxml and React? First, let me insist that I have zero experience with functional reactive interface, Tyxml or React. So I'm not in a very good position to comment on them! My *intuition* is that the tradeoff would be a bit similar to the one with Jane Street's Incremental. Both FRP and SAC require to introduce extra concepts (signals, events, variables, observers; specific maps and binds) which add some weight compared to a simple one-directional "view" mapping from state to vdom. What you gain with those approaches is a more fine-grained notion of update, which can be necessary in some cases. Interestingly, Elm moved away from FRP : http://elm-lang.org/blog/farewell-to-frp . This is not just a shift of terminology, and it corresponds to the removal of the "Address" argument on the view function in favor of a parametrized vdom type: https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.17.md#no-more-signaladdress (In a sense, the "Address" argument is rather similar to the "inject" function which we discussed with Yaron.) About Tyxml itself: I think that it addresses a rather different set of issues (ensuring that the DOM is "statically correct" w.r.t. definition of HTML5/SVG). We haven't identified those issues as being relevant for us, i.e. we have never hit a bug related to breaking such validity constraints, and the lack of static typing does not seem to make refactoring UI code more difficult or fragile; so it's not clear to us that adding more static typing here would help. If we tried to combine it with our vdom approach, it would probably add some noise, since the vdom type would receive extra type parameters, which would be visible in the interface of all components exposing "view" functions.Vincent Balat then said and Alain Frisch replied:
> Using Tyxml with React is straightforward and makes your pages reactive > almost for free. > > If your page contains : > p [ text (string_of int i) ] > you juste replace this by > p [ R.text (React.S.map string_of int i) ] > > and it is automatically updated when the value of i changes ... > > And with Eliom you can even created these reactive pages from server side ... I'm not sure to follow: in the "Elm/vdom" approach, the original p [ text (string_of int i) ] has the behavior you describe: the content of the text node will always be equal to "string_of_int i" and you don't have to do any explicit update to achieve that. That's the beauty of the model. I guess this could be qualified as "reactive" as well, except that the entire view is refreshed when any part of the state change (and the vdom diffing approach makes this viable).Yaron Minsky also replied to Alain:
> First, let me insist that I have zero experience with functional reactive > interface, Tyxml or React. So I'm not in a very good position to comment on > them! > > My *intuition* is that the tradeoff would be a bit similar to the one with > Jane Street's Incremental. Both FRP and SAC require to introduce extra > concepts (signals, events, variables, observers; specific maps and binds) > which add some weight compared to a simple one-directional "view" mapping > from state to vdom. What you gain with those approaches is a more > fine-grained notion of update, which can be necessary in some cases. I think FRP and SAC are pretty different in their roles here. Really, SAC is just a system for optimizing a unidirectional computation --- in the end, your view is pretty close to a function of this signature: val view : Model.t Incr.t -> Vdom.t Incr.t which is really just an incremental version of an ordinary function. You don't have to think about anything signal-like when you consider the semantics of your function: the semantics are exaclty what you get if you replaced every monadic bind with an ordinary let-binding. My somewhat biased view is that SAC addresses performance, which is an issue of fundamental importance for UIs, whereas FRP doesn't address a problem which is similarly central. And the ability to express time-dependent computations (which FRP provides) adds lots of other problems (in particular, monadic FRP is plagued by space leaks.) > Interestingly, Elm moved away from FRP : > http://elm-lang.org/blog/farewell-to-frp . This is not just a shift of > terminology, and it corresponds to the removal of the "Address" argument on > the view function in favor of a parametrized vdom type: > > https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.17.md#no-more-signaladdress > > (In a sense, the "Address" argument is rather similar to the "inject" > function which we discussed with Yaron.) Having talked to Evan a decent amount about this, my takeaway is that FRP in Elm wasn't really used to improve performance, and without that, it wasn't worth the conceptual weight. Incremental adds some conceptual weight (less, I claim, than traditional FRP libraries), but it also solves a real problem. React and Elm style solutions are simply not capable of implementing highly efficient views of fast changing data; indeed, they typically use special-purpose imperative libraries for implementing applications that require it. Incremental lets you do this kind of optimization in one smooth, functional framework. The cost, obviously, is you need to be comfortable living in a monad. For our developers, this doesn't count as that much of a cost these days, given the proliferation of other monadic abstractions in our code. But it's not trivial. > About Tyxml itself: I think that it addresses a rather different set of > issues (ensuring that the DOM is "statically correct" w.r.t. definition of > HTML5/SVG). We haven't identified those issues as being relevant for us, > i.e. we have never hit a bug related to breaking such validity constraints, > and the lack of static typing does not seem to make refactoring UI code more > difficult or fragile; so it's not clear to us that adding more static typing > here would help. If we tried to combine it with our vdom approach, it would > probably add some noise, since the vdom type would receive extra type > parameters, which would be visible in the interface of all components > exposing "view" functions. We support both TyXML and a simpler, untyped vdom API. My personal view pretty much matches yours, but other users (Hugo Heuzard in particular) prefers it pretty strongly. The lack of an extra type parameter in our approach makes the integration with TyXML easier, I suppose.Ashish Agarwal then added:
I don't have a strong opinion either way, but one point not mentioned about Tyxml is that you get nice auto-completion when combined with merlin. I've been pleased to learn the possible values for some attributes while coding without having to reference any documentation.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00115.htmlDeep in this thread, Vincent Balat announced:
The Ocsigen team is going to release Eliom 6 next week, which focuses on mobile apps. We will also release Ocsigen Start, a template with an example of multi platform application: a single code for both your Web app and mobile html5 apps (Android, iOS, Windows). If you want to see an example, download the Be Sport app on Google Play or Apple app store and have a look at the Web app. They are all using Eliom 6 and Ocsigen Start. https://play.google.com/store/apps/details?id=com.besport.www.mobile https://itunes.apple.com/us/app/besport/id1104216922 It is not native code but the performance are good (even if we have some problems on iOS, Apple's webview being very buggy). And this technique requires to write only one code for all your apps (even with server side generated pages for the Web version!). Ocsigen Start will be released probably next week (we are polishing the documentation) but is mature enough for large applications (as you can see with Be Sport). We are also using the Cordova bindings by Danny Willems, for some features.Ian Zimmerman then asked and Vincent Balat replied:
> Is there (or can there be <grin/>) a place to get the app, other than > the google store? > > I use CyanogenMod and F-Droid exclusively; I'm very curious about this > technology, but not enough to start using google again. If you don't want to use Google Play, you can get the Android application from here: http://besport.com/besport-103010.apk
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-12/msg00014.htmlBruno Bernardo announced:
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-12/msg00026.htmlJeremie Dimino announced:
I am pleased to announce the first alpha release of the Base library. Base is a standard library for OCaml. It is not an extension but rather a wholesale replacement of the standard library distributed with the OCaml compiler. In particular, it makes different choices and doesn't re-export features that are not fully portable such as I/O, which are left to other libraries. This release is not production ready, several things are still missing and some APIs will change before the first release. However, all the features we wanted to include to ensure that Base is a serious alternative to the standard library are now setup and working. Most of these features concern the build of Base: 1. Base has zero dependencies, except for its build system. In particular, it doesn’t require ppx rewriters and builds without make or even bash. This is true for both release tarballs and for the git repository itself 2. Base doesn't use module packs, instead it uses module aliases. This means that if you link against Base you will link against only the subset of modules that is needed 3. The layout of the code base is the one you would expect, i.e. Base.String is implemented in src/string.ml The roadmap for the first stable release is described in the README of Base. Along with Base, we are releasing two new packages: Stdio and Jbuilder. Base aims to be fully portable and therefore doesn't provide I/O functions. These are re-exported from the OCaml standard library as the Stdio library. Jbuilder is a build system that interprets the jbuild file format used at Jane Street to describe libraries and executables. It is intended as a release build system; it has zero dependencies outside of the OCaml compiler and aims to be fast and portable. The long term goal is to be able to use the same rules with both Jbuilder and Jenga, so that one can develop comfortably with Jenga and release with Jbuilder. Base, Stdio and Jbuilder are in the main opam repository and their code is available on github: - https://github.com/janestreet/base - https://github.com/janestreet/stdio - https://github.com/janestreet/jbuilder Note that the development versions of Jane Street packages currently don't build against Base 0.1.alpha1. They will be updated next week.Malcolm Matalka asked and Jeremie Dimino replied:
> What's the relationship between Base and Core? is this another std > library in the mix or does it replace Core as a stdlib alternative? Core is a richer stdlib that supersedes Base. More precisely, Core_kernel supersedes Base and Core supersedes Core_kernel. Core_kernel adds bin_prot as well as some other features that are not necessarily as general purpose than what is in Base. Core adds less portable features and depends on Unix. But the main difference between Base and Core_kernel is that Base comes first in the dependency graph. In particular, we can't use Core_kernel in sexplib, bin_prot or any ppx rewriter used in Core_kernel. As a result we end up reimplementing the same functions over and over again. Moreover improvements to Core_kernel don't benefit sexplib or bin_prot. Now everything has the same base. Given that Base has much less dependencies than Core_kernel, it should also be more attractive to people who want to keep a low number of dependencies.
Here are links from many OCaml blogs aggregated at OCaml Planet, http://ocaml.org/community/planet/. 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 Back End Functional Developer at NYU (Full-time) https://functionaljobs.com/jobs/8973-back-end-functional-developer-at-nyu
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.