OCaml Weekly News Previous week Up Next week

Hello

Here is the latest OCaml Weekly News, for the week of December 13 to 20, 2016.

  1. Eliom 6.0: mobile and Web apps in OCaml
  2. Deprecation of tabulation boxes
  3. Other OCaml News

Eliom 6.0: mobile and Web apps in OCaml

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

Vasilis Papavasileiou announced:
We are very happy to announce the release of Ocsigen Eliom 6.0 [1],
which follows the recent releases of Ocsigen Server 2.8 [2] and
Ocsigen Js_of_ocaml 2.8.x [3].

New features include a friendlier service API that retains the
expressive power of our service system. Additionally, Eliom can now be
used to build cross-platform Web/mobile applications (Android, iOS,
...).

## What is Eliom?

Eliom is a framework for developing client/server web
applications. Both the server and the client parts of the application
are written in OCaml, as a single program. Communication between
server and client is straightforward, e.g., one can just call a
server-side function from client-side code.

Eliom makes extensive use of the OCaml language features. It provides
advanced functionality like a powerful session mechanism and support
for functional reactive Web pages.

## Friendly service APIs

Services are a key concept in Eliom, used for building the pages that
are sent to the user, for accessing server-side data, for performing
various actions, and so on. Eliom 6.0 provides a friendlier API for
defining and registering services, thus making Eliom more
approachable.

The new API makes extensive use of OCaml's GADTs, and provides a
single entry-point that supports most kinds of services
(`Eliom_service.create`). For more information, refer to the
Eliom manual [4].

## Mobile applications

Eliom 6.0 allows one to build applications for multiple mobile
platforms (including iOS, Android, and Windows) with the same codebase
as for a Web application, and following standard Eliom idioms.

To achieve this, we have made available the Eliom service APIs on the
client [5]. Thus, the user interface can be produced directly on the
mobile device, with remote calls only when absolutely necessary.

To build an Eliom 6.0 mobile application easily, we recommend that you
use our Ocsigen Start [6] project, which provides a mobile-ready
template application. Ocsigen Start is currently available in OPAM as
a preview, with an 1.0 release coming soon.

## Compatibility

Eliom 6.0 supports the last 3 major versions of OCaml (4.02 up to
4.04). Additionally, Eliom is compatible with and builds on the latest
Ocsigen releases, including Ocsigen Server 2.8, Js_of_ocaml 2.8.x, and
TyXML 4.0.x.

## Future

The Ocsigen team is busy working on new features. Notably, we are
developing an OCaml compiler [7] specifically tuned for
Eliom. Additionally, we are planning a transition to the Cohttp
backend.

## Support

- Migration guide: https://ocsigen.org/eliom/Eliom60
- Issue tracker: https://github.com/ocsigen/eliom/issues
- Mailing list: https://sympa.inria.fr/sympa/info/ocsigen
- IRC: `#ocsigen` on `irc.freenode.net`

[1]: https://github.com/ocsigen/eliom/releases/tag/6.0.0
[2]: https://github.com/ocsigen/ocsigenserver/releases/tag/2.8
[3]: https://github.com/ocsigen/js_of_ocaml/releases/tag/2.8.3
[4]: https://ocsigen.org/eliom/dev/manual/server-services
[5]: https://ocsigen.org/eliom/manual/clientserver-services
[6]: https://github.com/ocsigen/ocsigen-start
[7]: https://github.com/ocsigen/ocaml-eliom
      

Deprecation of tabulation boxes

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

Ivan Gotovchits asked:
The tabulation boxes are marked as deprecated since 4.03.0. I've tried to google
for any reasons that justify the removal but found only a note by Pierre Weis in
the Matis issue tracker[1]:

 The proposed printf-like syntax is fine, but tabulation boxes are now
 deprecated. Indeed, tabulation boxes interaction with other pretty-printing
 boxes have never been sorted out and tabulation boxes usage is orthogonal to
 the rest of the Format module. If considered useful, tabulation boxes could be
 implemented out of the Format module.

First of all the tabulation boxes can't be implemented outside of the format
module since the tab stops are actually stored in the stack of tabulation boxes.
If this data field would be removed from the formatter we will need to pass an
extra argument to all pretty-printers that use the tabulation break, or use some
global variable. Neither solution can be considered acceptable.

Speaking about the usefulness. The tabulation boxes are useful for printing
assembly outputs. And since compiler writing is sort of an application area for
OCaml, it shouldn't be considered as a rare case. It is also very useful for
printing Fortran code, that can be considered an assembler for the numeric
computing. It also just allows printing nicely formatted texts, that it the main
purpose of the Format library. As an example, tabulation boxes are used in BAP
and CIL frameworks.

To summarize, the deprecation will eventually make few project non-compilable.
And there is no clear substitution for the deprecated feature.

Given that, I would like to hear the justifications for the deprecation of
tabulation boxes and suggested workarounds.

One possible workaround, that I could see, is making the `formatter` type
extensible with existential boxes or, more generally, with existential
attributes. In that case, we will indeed be able to implement tabulation boxes
outside of the format module.

Best wishes,
Ivan Gotovchits

[1]: https://caml.inria.fr/mantis/view.php?id=4665
      
Gabriel Scherer replied:
You may be interested in the discussion
  https://github.com/ocaml/ocaml/pull/229
which discussed a few ways in which the proposed tabulation interface
may be inconvenient. It is after this discussion that Pierre Weis
decided to deprecate tabulation boxes -- I believe that the reason is
that tabulation and formatting never mixed very well.

Note that if you can decide in advance a maximal size for a given
"column" of your formatted output, you can use the left or
right-justification features of formatting conversions to print
aligned text:

let data = [("x", "foo"); ("loop", "bar")]

let () =
  print_newline ();
  data |> List.iter (fun (lab, instr) -> Printf.printf "%5s: %s\n" lab instr)
(*
    x: foo
 loop: bar
*)

let () =
  print_newline ();
  data |> List.iter (fun (lab, instr) -> Printf.printf "%-5s: %s\n" lab instr)
(*
x    : foo
loop : bar
*)

let () =
  let len = List.fold_left (fun m (lab, _) -> max m (String.length
lab)) 0 data in
  print_newline ();
  data |> List.iter (fun (lab, instr) -> Printf.printf "%*s: %s\n" len
lab instr)
(*
   x: foo
loop: bar
*)
      
Ivan Gotovchits then said:
Well, the discussion literally says, we don't understand tabulation, and it
looks like nobody is using it, so let's just throw it away :)

We're using tabulation, and they are quite useful. Yep, I agree, that the
interface for setting the marks is kind of awkward, it would be nice if there
would be a `pp_setup_tabs : _ formatter -> int list -> unit` function, that
would push into the stack a new tabular box with the specified tabulations.

What concerning your solution with the alignment, it is less general and doesn't
work in our case. First of all, the pretty printing functions, that are printing
into the columns are not specified with `%s`, but with `%a` (e.g., address,
memory string, assembly string). Second, the printing functions are not actually
defined in the same module. The tabs are initialized in the frontend, that
defines it based on the architecture (address size, maximum length of
instruction, etc), and pretty printers are registered separately, and they just
rely on a fact, that we have three columns, the first is for address, the second
is for memory, then assembly, etc). This design simplifies the actual
instruction printers, by consolidating the common code in the formatter setup
procedure.

So, it is still not clear to me, why the tabulations are wrong. If they do
complicate the code base and raise the support cost, then it is understandable,
why you would like to remove it from the standard library. But in this case, it
would be nice, to move this code out as a separate library, as just removing a
feature, that was in the language for years (I would say even forever, if we
will start the history from caml-light), without providing any substitution
is... not nice :)

[1]: http://caml.inria.fr/pub/docs/manual-caml-light/node15.5.html
      

Other OCaml News

From the ocamlcore planet blog:
Here are links from many OCaml blogs aggregated at OCaml Planet,
http://ocaml.org/community/planet/.

vile 9.8s
 http://blog.0branch.com/posts/2016-12-18-vile-9.8s.html

Merlin promoted to headline OCaml project
 https://ocaml.io/w/Blog:News/Merlin_promoted_to_headline_OCaml_project

Coq 8.6 is out
 https://coq.inria.fr/news/134.html
      

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