Re: [Plplot-devel] Migrating the OCaml bindings to the official PLplot repository

[Hezekiah M. C. <hc...@at...>]

On Tue, Mar 11, 2008 at 5:32 AM, Andrew Ross
<and...@us...> wrote:
>  I agree that swig would be good to minimise maintenance effort. I see
>  that the camidl approach needs (another) modified copy of plplot.h. Swig
>  would presumably use the existing plplotcapi.i file. Having said that,
>  if there are convincing technical reasons for using camidl I could be
>  persuaded.

The plplot_h file (yet another modified plplot.h) is a definite
down-side to the camlidl approach to generating these bindings.
However, even with that issue I think maintenance of the OCaml
bindings will be easier with camlidl and, as you quoted from one of my
previous emails the resulting OCaml interface is much lighter weight.

The maintainer of the swig-based OCaml bindings (found here:
http://vityok.org.ua/cgi-bin/odd.cgi/Ocaml-plplot) has said that they
are unable to dedicate the time to continuing upkeep of those
bindings.

One of the main reasons I chose camlidl over swig as a binding aid is
that camlidl handles C -> OCaml types in a much more clean and direct
fashion than swig does.  In order to make the swig-based OCaml
interface look like the C API, every function has to be wrapped in
extra OCaml code to extract or copy values from swig generated
wrappers.  In the case of camlidl you end up with this interface
without the extra code.  This is partly due to camlidl being very
OCaml specific and covering fewer C and C++ features out of the box
than swig does.  PLplot's C api is thankfully quite simple overall, so
camlidl can handle the vast majority of the functions without much
manual intervention.  The end result is a very OCaml-friendly
interface without a lot of extra hand-coding.

The functions that camlidl does not handle on its own (functions
taking callback parameters mainly) are wrapped by hand.

As an example, moving from a plplot_h based on 5.7.3 to one based on
5.9.0 (admittedly not a huge change, but did include the char* ->
const char* and several new functions) took me much less than an hour,
including getting the PLplot code, installing it and updating the
OCaml parts.  The steps I used to do so are indicated here if you want
a better description of the process:
http://code.google.com/p/ocaml-plplot/wiki/HowItWorks

I hope this clarifies why I think camlidl is still the way to go for
the OCaml interface.  I am quite open to further discussion though if
needed.

Sincerely,
Hez

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science