Here is the latest OCaml Weekly News, for the week of December 27, 2016 to January 03, 2017.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-01/msg00000.htmlOleg 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.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-01/msg00002.htmlContinuing 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 :)
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-01/msg00008.htmlChet 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.
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
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.