OCaml Weekly News Previous week Up Next week

Hello

Here is the latest OCaml Weekly News, for the week of November 29 to December 06, 2016.

  1. llpp v25
  2. ocaml-vdom (pre-release)
  3. Android/iOS apps with OCaml
  4. Next OUPS meetup, Dec. 6th 2016
  5. Base, Stdio and Jbuilder 0.1.alpha1
  6. Other OCaml News

llpp v25

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00112.html

moosotc 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(-)
      

ocaml-vdom (pre-release)

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00113.html

Alain 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-vdom
      
Yaron Minsky and Alain Frisch then discussed:
Yaron:
>> Alain, this looks awesome! We'll take a look at this and maybe use it
>> instead of the javascript library we're currently depending on here:
>> 
>> https://github.com/janestreet/virtual_dom
>> 
>> I'm curious if you have any story for making the recomputation of the
>> virtual-dom itself more efficient. Right now, we're using incremental
>> for this part of the story, as reflected here:
>> 
>> https://github.com/janestreet/incr_dom
>>
>> That said, for small UIs, this kind of incrementality is less
>> important, so whether this is worth doing may depend on your
>> applications.

Alain:
> Our story w.r.t. updating the vdom itself is the same as Elm, I believe:
>
> 1. In the vast majority of cases, the mapping from the "state" to the vdom
> is very quick and it is ok to recompute the full vdom on every state change.
>
> An argument often made in the vdom space is that a UI usable by human-beings
> cannot possibly have a very big DOM (moreover, even recent browsers such as
> the latest Edge or Firefox struggle with tables starting at a few thousands
> rows), and that computing the full vdom "cannot be that costly".  I don't
> want to enter such discussion here, but in our own use cases, we indeed try
> to avoid "overly big UIs" and we don't have strong performance requirements
> such as continuous streams of updates pushed by the server; if it takes 10ms
> to react on a user UI event, it is perfectly fine for our case.  My
> intuition is that most applications would be a similar situation, but I
> appreciate that you have very different kinds of UIs and performance
> constraints that require a more incremental approach.

Yaron:
I do think for even moderate size views of data (big tables, graphs,
etc.) this argument stops working pretty quickly, but I agree there is
a large scope of applications for which this is true.

It's worth noting that we use Incremental to pull off what we've
called "partial rendering", which is to render a table with, say, 10k
rows, but only actually rendering the 60 or so that are actually in
view. This makes what would otherwise be rather sluggish applications
quite zippy.

Alain:
> 2. The library provides:
>
> val memo: ?key:string -> ('a -> 'msg vdom) -> 'a -> 'msg vdom
> (** Apply the function to generate a VDOM tree only if the function
>     or its argument have changed (physically) from the previous
>     synchronization. *)
>
> (similar to Elm's Lazy:
> http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Lazy )
>
> This is typically used when embedding the view of a "sub-component" derived
> from only part of the our current state.  If we can ensure this sub-part
> remains the same, the previous vdom (at the same "site") is reused, which
> skips both the vdom generation and the vdom diffing. Typically, the
> generation function would be a toplevel declaration (so it will always be
> the same, physically) and we arrange to avoid touching the part of the
> global state on which it depends.
>
> Of course, it is also possible to use any other mechanism (such a
> memoization table) to reuse previously computed vdoms.

Yaron:
One downside of the Elm style approach is that physical equality is
brittle, e.g., if you end up constructing something that's logically
but not physically equal, you can end up recomputing a lot more than
you might have expected. I do think making it possible to add a custom
equality function makes this a bit better, and is an easy change to
make.

Yaron:
>> Another thought: you might want to consider the design we used for our
>> wrapper on Matt Esch's virtual-dom library. In particular, in our
>> design we don't need a type-parameter for vdom nodes determining the
>> type of a message, and we don't need the corresponding map
>> functions. Instead, we use open types and a registration and dispatch
>> mechanism for values thus injected.

Alain:
> Thanks for the hint.
>
> Do you have pointers to code examples using the "inject" function?  It seems
> to me that you will need to apply to it produce any "message" in the view
> function.
>
> In our library, you can write directly:
>
>      input "+" ~a:[value "+"; type_button; onclick `Plus]
>
> With the "inject" approach, do you need to write it like:
>
>      input "+" ~a:[value "+"; type_button; onclick (inject `Plus)]
>
> ?

Yaron:
Here's an example:

https://github.com/janestreet/incr_dom/blob/master/example/incr_decr/counters.ml

And the tradeoffs you imply is indeed there. I find the code without
the type parameter easier to use and think about, but I agree that the
"lightness" argument isn't 100% clear.

Another advantage of the Event approach is that we have combinators
like Event.Many that let you deliver a list of events together, and
primitive events like Stop_propagation and Viewport_changed, which are
always available, independent of the concrete event type. We've found
this to be quite useful in separating out the pure and imperative
parts of the application.

Alain:
> If so, this does not seem strictly lighter than using the "map" function
> occasionally.  Moreover this seems to open the door to possible problems if
> a vdom fragment producing some kinds of messages is injected in a "host
> application" that cannot process these messages.  It also means that one
> needs to take the identity of the "inject" function itself into account in
> order to memoize vdom-generation functions.

Yaron:
The issue about the identity of the inject function is real, and the
use of Incremental helps us here, making it easy to preserve physical
identity. Also, Incremental allows you to be freer in your use of
functional programming idioms, letting you pass closures around to the
various render functions without destroying physical equality.

As far as I understand it, the Elm-style approach tends to require a
fairly first-order style in order to make memoization effective.

That said, using Incremental is a pretty heavy hammer to solve this
problem, so if you don't care about incremental computation more
generally, it's not clear it's worth the trouble.

Alain:
> Basically, we need "map" on "component boundaries", and even not always,
> since components can take ad hoc injection functions to wrap their messages
> into their "host" own message type (as the SelectionList example in
> https://github.com/LexiFi/ocaml-vdom/blob/master/examples/vdom_ui.mli ).
>
> The library does use extensible types (with a registration/dispatch
> mechanism) in two other places, though:
>
>   - "Commands" (encapsulation of side-effectul operations).  The set
>     of "command constructors" is small and has a global nature
>     (e.g. "AJAX query", "timer", etc), while the type of "messages"
>     is specific to each application and component.

Nice. This is part of what we're doing in our Event type.

>   - "Custom nodes" in the VDOM which allow plugging "native"
>     components (again, the set of such possible components is more
>     "fixed" than messages).

Interesting. I'll take a look.
      
Martin DeMello asked and Alain Frisch replied:
> 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.
      

Android/iOS apps with OCaml

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00115.html

Deep 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
      

Next OUPS meetup, Dec. 6th 2016

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-12/msg00014.html

Bruno Bernardo announced:
The OUPS meetup is back. The next one will take place on Tuesday,
Dec. 6, 7pm at IRILL on the Jussieu campus. (Sorry for the late announcement!)
As usual, we will have a few talks, followed by pizzas and drinks.

The talks will be the following:

- Hongbo Zhang on BuckleScript - seamless integration with JavaScript ecosystem. 
- Gabriel Radanne on Tyre : Typed Regular Expressions
- Marc Lasson on Landmarks: A Simple Profiling Library

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/235672152/
*Registration is required! Access is not guaranteed after 7pm if
you're not registered.* (It also helps us to order 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://goo.gl/maps/EjvCFrKSXRs
The meetup organizers.
      

Base, Stdio and Jbuilder 0.1.alpha1

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2016-12/msg00026.html

Jeremie 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.
      

Other OCaml News

From the ocamlcore planet blog:
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
      

Old cwn

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.


Alan Schmitt