From: Mauricio Fernandez <mfp@...>
Date: 2007-06-24T01:04:10+09:00
Subject: Re: [ANN] rocaml: Ruby extensions in Objective Caml

On Fri, Jun 22, 2007 at 09:31:12PM +0900, benjohn@fysh.org wrote:
> Hi Mauricio,
> 
> a quick thought that I'm pretty sure you've already had: I notice that
> you define the interface in Ruby, and also define what should be
> exported in OCaml. Couldn't you, say, just define it in OCaml (where the
> type sigantures will be know completely, I guess?), and have the Ruby
> interface generated from this?

Even though the types are known by the compiler, human intervention is needed
at some point because:
* we have to define what needs to be exported
* the naming and parameter passing conventions might differ (e.g. the
  data structure often being given after the element to operate with in
  functional data structures)
* polymorphic functions have too broad a type, and the concrete
  type(s) you want must be specified. For instance, in the RB tree example,
  two classes are generated for sets of strings and ints. Their instance
  methods correspond to the same polymorphic OCaml functions, but providing
  the desired concrete types allows the wrapper generated by OCaml to perform
  the necessary type checking and Ruby->OCaml conversions. The alternative
  would be wrapping Ruby values in OCaml with an abstract universal type, but
  introducing dynamic typing defeats the purpose of writing an extension in
  OCaml to some extent (it'll be slower and the type system will not help you
  that much).

That said, it would be possible to encode all that information in a .ml file,
instead of splitting it into an OCaml part (which functions are to be
exported) and another in Ruby, in extconf.rb (how that functionality is
accessible from Ruby, and the method signatures). It's a bit harder to
implement though, as building the extension would involve an extra stage to
compile the file holding that information and extract it in order to generate
the wrapper. Going the other way around, specifying it all in extconf.rb and
generating the .ml code that registers the functions from it would be very
easy to implement, but would force one to use named functions(1).

In the meantime, I don't find the need to register the functions in OCaml too
onerous, as it's at most one line per method, and the extra degree of freedom
in the OCaml -> Ruby mapping is quite convenient (I can do e.g. parameter
reordering with an anonymous function).

(1) another benefit from that would be the possibility to check that the
specified types are included in those from the .cmi (a file generated by OCaml
with interface information)
-- 
Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby