Previous week Up Next week

Hello

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

  1. BER MetaOCaml N104, for OCaml 4.04.0
  2. Deprecation of tabulation boxes
  3. C++ for Ocaml FFI bindings
  4. Other OCaml News

BER MetaOCaml N104, for OCaml 4.04.0

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-01/msg00000.html

Oleg announced:
BER MetaOCaml N104 is a strict superset of OCaml 4.04.0 for ``writing
programs that generate programs''.  BER MetaOCaml adds to OCaml the
type of code values (denoting ``program code'', or future-stage
computations), and two basic constructs to build them:
quoting and splicing. The generated code can be printed, stored in a
file -- or compiled and linked-back to the running program, thus
implementing run-time code optimization. A well-typed BER MetaOCaml
program generates only well-scoped and well-typed programs: 
The generated code shall compile without type errors. 
Staging-annotation-free BER MetaOCaml is identical to
OCaml; BER MetaOCaml can link to any OCaml-compiled library (and
vice versa); findlib and other tools can be used with BER MetaOCaml as
they are, in their binary form.

BER MetaOCaml N104 comes with one minor and two notable improvements.
The minor improvement is the availability of the native MetaOCaml.  If
the generator is compiled in native mode (using metaocamlopt), the
dynamically generated and run code will be natively-compiled as
well. The lack of native mode was the most frequently heard criticism
of MetaOCaml, although in my experience it hardly even
matters. Off-line code specialization seems to be far more prevalent
and useful than online one. Anyway, here we have it.

The notable new features -- not seen in MetaOCaml (or MetaML, for that
matter) -- are generating pattern-matching expression with the
statically unknown number of clauses, and let-insertion as a
primitive. To wit, |genlet exp| inserts  |let freshname = exp in ...| 
somewhere in the generated code and returns |.<freshname>.| (unless |exp|
is already syntactically a value such as a variable reference).
The let-statement is inserted at the most appropriate place.

BER MetaOCaml N104 should be available though OPAM, hopefully soon.
In the meanwhile, it is available as a set of patches to the 
OCaml 4.04.0 distribution. 
        http://okmij.org/ftp/ML/ber-metaocaml-104.tar.gz
See the INSTALL document in that archive. You need the source
distribution of OCaml 4.04.0, see the following URL for details.

For more explanations, please see
        http://okmij.org/ftp/ML/MetaOCaml.html
as well as ChangeLog and NOTES.txt in the BER MetaOCaml distribution.
      
Gabriel Scherer then said:
Congratulations on this interesting new release.

Below are some minor remarks I had while looking at what you wrote on
this release and its new features.

One. I am not familiar with the MetaOCaml implementation but,
intuitively, I wondered why attributes were used instead of
extensions. In my book, (e [@attr]) is supposed to be an OCaml term
that behaves as the expression (e), with some extra (tooling- or
optimization- related) expression of intent. On the contrary, [%ext e]
is allowed to have any semantics at all. One could even argue that it
is semantically wrong to use attributes for MetaOCaml (as their forms
do change the semantics), although that concern is alleviated by the
use of the foreign-looking syntax .< ... >. which also indicates that
something non-standard is going on.

One interesting thing with the addition of the two new syntactic
classes "pattern" and "value" is that, from a syntactic point of view,
the idea of using extensions directly instead of home-grown syntax
starts looking more reasonable: [%quote e], [%quote.pat e],
[%quote.val e] (plus long forms metaocaml.quote*). Moving from .< e >.
to [%quote e] is still arguably a bad deal for readability, but for
the other two forms it would actually be an improvement over the
current syntax. So I guess the benefit would depend a lot on how often
these two new forms end up being used by MetaOCaml programmers. Using
the extension syntax directly would certainly simplify a few things
around MetaOCaml -- zero need for non-standard parsing, for example.

Two. It is interesting that you mention that "function" allows to
easily represent sets of clauses as expressions, as I was recently
thinking about which kind of constructions would be made possible by
taking "sets of clauses" as a first-class syntactic category.

Three. I was professionally obligated to remark your formulation on
where (genlet exp) actually places its definition: "The `let` is
inserted right under the binder for the "latest" free variable
contained in `exp`". This is exactly the style of placement used in
sum-equivalence algorithms (and, I suppose, work on partial
evaluation), typically the delimited-control-using presentation of
"Extensional normalisation and type-directed partial evaluation for
typed lambda calculus with sums" by Vincent Balat, Roberto Di Cosmo
and Marcelo Fiore, 2004. Interestingly, these algorithms do not (only)
place let-bindings in this way, but also case statements -- they want
the case-distinction on the bound value to have as large a scope as
possible. This suggests that maybe the "finding the earliest place to
introduce an expression" is a really useful primitive to have for
metaprogramming, and that your "genlet" could be reconstructed from
it, but right now I don't see how to expose it without letting the
user do delimited control -- which is what you started from.
      

Deprecation of tabulation boxes

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-01/msg00002.html

Continuing this thread, Pierre Weis said:
Sorry for the late answer: I generally have no time to read the Caml-list...

As Gabriel said, I deprecated the tabulation boxes after a discussion about
their not so smooth integration with other features of the Format module. And
as you mentioned it, the discussion can be summerize as ``we do not
understand the feature and do not use it'', and so probably nobody use it.

I should have been more careful and wait to check if some users in the field
were using tabulation boxes in their code.

The problem about tabulation boxes is that they cannot be easily mixed with
other boxes; on the other hand, if you do know the fact, they are perfectly
usable to do exactly what you are doing with tabulation boxes, i.e. basic
and simple tabular printing. That's exactly why those boxes have been
introduced in Format in the first place: to print text file using lines with
fixed fields separated with spaces or tabs (basic tab-tab-return line format).

However, the code for tabulation boxes is still there and still up and
running. So reverting its status is easy and should not break anything: it
could be done anytime.

During last year, Richard Bonichon and I wrote a paper about Format, its
features, usage, internals and principles, to be presented at the next
JFLA'2017 conference. During this work, we had long brain storming sessions
about the new features I'm planning to introduce in the module and in
particular a new tabular printing feature that would subsume tabulation
boxes, since tabular printing would be fully integrated to the regular box
management (and would have a proper format string extension to express
tabular printing). This is still paper work, but we are confident to get a
draft of the code during 2017.

So, now that we know that some people indeed use the tabulation box feature,
I propose to revert its status. When the new tabular printing feature will be
there, people could easily port their code to the new feature and we could
definitely deprecate the old tabulation boxes.

PS: I wish you the best for this new year :)
      

C++ for Ocaml FFI bindings

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-01/msg00008.html

Chet Murthy announced:
Hi, I've been watching the discussions over the years regarding FFI
bindings from Ocaml.  I've built a ton of such bindings using Camlidl.
I've used some done using Ctypes.  And it's always hard.  But
recently, I've come to the conclusion that bindings against C++ would
be (shockingly, yes I know) -easier- than against C.

To demonstrate this, and because I had need of it, I've writte a
little IDL compiler, along with an example FFI wrappering of the C++
Rocksdb API.  Only as an example.  The code is raw, and really
.... raw.  But it works, works well, and is dreamily easy to add new
entry-points to.  I'm hoping that over the next few weeks, as I use
this, I'll add tests, more examples, and documentation.

  --> oboy, does it need documentation (if anybody but me is -ever-
      gonna use it)

Right now though, I just thought I'd send this note, to try to raise
the subject that ....

  Maybe C++ is a ripe target for FFIs from Ocaml?

I've released the code (such as it is) on Github:

https://github.com/chetmurthy/ocaml-cppffigen

https://github.com/chetmurthy/ocaml-rocksdb

Please don't take this as an advertisement for the code.  But do take
it as an advertisement for the -idea-.
      
Fabrice Le Fessant then said:
I wrote a very basic tool to generate OCaml bindings for the WxWidgets C++
library (https://github.com/OCamlPro/ocplib-wxOCaml), and then a very different
one for LLDB (https://github.com/OCamlPro/typerex-lldb). In both cases, methods
of C++ class A are mapped to functions of OCaml module A. The main difference is
that WxWidgets makes heavy use of inheritance, while LLDB does not use it at
all. Consequently, there are many "cast" functions in WxOCaml, while there are
none for LLDB. Also, LLDB is very strict on the syntax of its include files,
which makes it very easy to parse them directly from OCaml (there is no need for
a DSL), whereas for WxWidgets, I had to copy and slightly modify the C++ method
definitions into a subset (the DSL) that could be used from OCaml.

So, in your bindings, which OCaml type do you target for a C++ class ? Also, is
there some support for garbage collection ? How do you detect that a C++ object
is removed, so that the corresponding OCaml object can be removed ? Is it
generalizable to any C++ framework ?
      
Immanuel Litzroth then replied:
It is possible to write generic C++ for mapping any C++ class as
a new type in ocaml by wrapping it in a shared_ptr or unique_ptr,
in such a way that the object can be kept alive by the c++ side or
by the ocaml side. There is some code on the net that explores that
idea here:
https://github.com/ygrek/scraps/blob/master/cxx_wrapped.h
but that seems to be using the older auto_ptr at the moment. The 
code I have written for this is proprietary.
      

Other OCaml News

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

Deprecating the Forge in 2017
 http://forge.ocamlcore.org/forum/forum.php?forum_id=958

CamlIDL; migration to Github
 http://forge.ocamlcore.org/forum/forum.php?forum_id=957

SpamOracle: migration to Github
 http://forge.ocamlcore.org/forum/forum.php?forum_id=956

ocamltopwin: migration to Github
 http://forge.ocamlcore.org/forum/forum.php?forum_id=955

ocamlmpi: migration to Github
 http://forge.ocamlcore.org/forum/forum.php?forum_id=954

Ocamlagrep: migration to Github
 http://forge.ocamlcore.org/forum/forum.php?forum_id=953

Camlzip: migration to Github
 http://forge.ocamlcore.org/forum/forum.php?forum_id=952

Camjava: migration to Github
 http://forge.ocamlcore.org/forum/forum.php?forum_id=951

Cryptokit: migration to Github
 http://forge.ocamlcore.org/forum/forum.php?forum_id=950
      

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