I’d like to announce a preview release of ocaml-r, a library that can be used to interact with the R language interpreter and write clean wrappers to R functions and packages. This library was developped a long time ago by Maxence Guesdon and Guillaume Yziquel, and I’ve maintained it since then for my own needs. The library is available on opam, under version 0.1.1, and on github [0].
The goal of this release is to see if other people could find it useful, in which case I can spend a little more time writing documentation on how to use it, and help write more wrappers. Please get in touch via the issue tracker if interested.
orsvm also wraps svmpath by the way, despite the package name which only mentions svm-e1071.
I am interested into wrapping the R package for ranger in the near future, because the R package
for ranger can handle sparse data.
If you show me that you can do such wrappers with OCaml-R, I would like to see a working example.
Of course not !
Joke aside, while the API you provide can certainly be the same, those bindings should be a lot easier to write with ocaml-r, since you don’t have to generate R code with strings and parse the output back to ocaml values.
Writing a wrapper is really not that difficult, but until recently I was really unsure what was the right way to structure an API, and how to type everything. After having played a lot with js_of_ocaml I’m growing more confident that the solution proposed in gen_js_api is the right one. Writing an equivalent generator for ocaml-r would be an interesting intern project I think.
For now, I have a “best-effort” stub generator that loads an R package, and generate part of the boilerplate. You can see it at work for base and utils libraries, but I’ll try to push more wrappers in the next weeks.
Speaking of typing, I noticed that some data structures returned from ocaml-r are objects; for instance the hist type iirc. Are objects the only reasonable choice or would a record have worked as well? Just curious.
Records could also work, the thing is that they require to be declared. So that would make one definition per function, with possibly common fields between functions. So the definition should be put in a single case variant or in a module. So objects seemed a good option to me here.
I see. I sometimes do end up defining a type which is then used only for a single record instance (simulation parameters set in a ‘run script’). Maybe I should also consider objects for that.
!