[cwn] Attn: Development Editor, Latest OCaml Weekly News

Tue Dec 27 09:02:04 PST 2016

Hello,

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

1) opam-cross-{windows,android,ios} with OCaml 4.04
2) off-brand use of ocaml bytecode

========================================================================
1) opam-cross-{windows,android,ios} with OCaml 4.04
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-12/msg00077.html>
------------------------------------------------------------------------
** whitequark announced:

I'm pleased to announce that opam-cross-windows[1],
opam-cross-android[2] and opam-cross-ios[3] now feature
an OCaml 4.04 toolchain, and all of the packages have been
brought up to date.

In addition, I would like to thank Hezekiah M. Carty
for porting many packages to Windows.

[1]: <https://github.com/whitequark/opam-cross-windows>
[2]: <https://github.com/whitequark/opam-cross-android>
[3]: <https://github.com/whitequark/opam-cross-ios>

========================================================================
2) off-brand use of ocaml bytecode
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-12/msg00091.html>
------------------------------------------------------------------------
** Hendrik Boom asked and Evgeny Roubinchtein replied:

I know there are people on this list who are way more qualified to answer these
questions, but let me try.

> Are there any tools available that could be used to generate ocaml
> bytecode for other languages?

I don't think you will get a definitive answer on this list. Here is a thought
experiment showing why. Suppose J. Random Hacker decides to write a compiler
from WhizBangLang to OCaml byte code. Under the assumption that OCaml developers
are not omniscient, the way they would learn about J. Random Hacker's efforts is
if s/he either: a) announces the new language in some venue that OCaml
developers watch or b) finds [what s/he believes are] bugs in the OCaml byte
code interpreter and files bug reports against it. It isn't clear to me that our
J Random Hacker must needs do either of those things.

> If I were to do that, by hand or otherwise, how would I interpret or
> compile it?

The ocamlrun program, shipped with the OCaml distribution and documented at
<http://caml.inria.fr/pub/docs/manual-ocaml/runtime.html> is the standard
interpreter for the OCaml byte code.

For the OCaml compiler, the byte code is a target (as opposed to a source or an
intermediate representation), so the existing OCaml tool chain does not support
compiling byte code, to the best of my knowledge (AFAIK projects like
Bucklescript and js_of_ocaml use the OCaml front-end and intermediate
representation, but supply a different compiler back end).

> Would the ocaml run-time system we available -- things like the garbage
> collector, I/O libraries, etc.

I think that question is answered in the documentation of ocamlrun. You probably
will also want to peruse <http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html>
and specifically the discussion of static and dynamic linking of C code with
OCaml code.

> Is anyone else working of projects like this?

I am not entirely certain what the intended antecedent of "this" is here. If
"this" is "a compiler that targets OCaml byte code", then please see my answer
above. If you feel that the current design of "ocamlrun for standard primitives
+ the '-custom' flag to the OCaml compiler for non-standard primitives" is
failing to address a need, then a description of the need that isn't being
addressed would be a good starting point for discussion. ;-)

** Yotam Barnoy suggested:

Check out Stephen Dolan's Malfunction
(<https://github.com/stedolan/malfunction>). You essentially compile
down to OCaml's internal representation, and the compiler takes it
from there, making either bytecode or native binaries.

** Gabriel Scherer also said:

There is one known case of the OCaml runtime being reused, namely the Coq
bytecode interpreter, which is a modified version of the OCaml bytecode
interpreter that supports a different evaluation strategy. This is described in
the article

A Compiled Implementation of Strong Reduction
Benjamin Grégoire and Xavier Leroy, 2002
<http://gallium.inria.fr/~xleroy/publi/strong-reduction.pdf>

This implementation duplicates (and simplifies) the instruction set and
interpretation loop, but it does reuse the same value representation and, I
believe, the OCaml runtime system (the GC in particular).

If you are interested in a documentation of the OCaml bytecode runtime, the two
following documents could be of help:
- Benedikt Meurer's article on his work on jitting the bytecode runtime begins
with a very clear how-level description of how the whole thing works in OCaml
today: <https://arxiv.org/abs/1011.1783>
- Xavier Clerc, while working on OCamlJava, produced a very detailed and
up-to-date reference of the OCaml bytecode instruction set (
<http://cadmium.x9c.fr/distrib/caml-instructions.pdf> )

(A more high-level description of the principles behind the instruction set, in
particular how it makes curried functions fast enough, can be found in Xavier
Leroy's course notes on "abstract machines and compilation", along with
comparisons with other designs of the 80s or early 90s and some correctness
proofs: <http://gallium.inria.fr/~xleroy/mpri/2-4/machines.pdf> )

** Hendrik Boom also replied:

Having started to leaf through a few pieces of documentation about
the OCaml compilation chain, I now figure that the lambda IR would 
probably be a better place to tap into the process. 

So I'll re-ask, this time sking about compiling from the internal lambda 
representation instead of the byte-code.

** Gabriel Scherer then added:

Maybe you should indeed consider Malfunction as Yotam mentioned in the
previous thread:
  <https://github.com/stedolan/malfunction>

It is a well-defined language made for producing code to go into the
OCaml compilation pipeline. You can think of it as a subset of the
lambda intermediate language, with a fixed (s-expressions) syntax and
parser, and a documentation of the behavior of its programs.

It is a bit simplistic (or at least it was last time I looked) but if
you have extra needs you could get in touch with the author (Stephen
Dolan) and work with him to extend it.

========================================================================
Old cwn
------------------------------------------------------------------------

If you happen to miss a CWN, you can send me a message
(alan.schmitt at polytechnique.org) and I'll mail it to you, or go take a look at
the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the
archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish
to receive it every week by mail, you may subscribe online at
<http://lists.idyll.org/listinfo/caml-news-weekly/> .

========================================================================

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2016-11: 403.53, 2015-11: 400.16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20161227/c477c75a/attachment.pgp>