Re: [Caml-list] [ANN] ocaml-lua v1.0: OCaml binding of Lua library

[Florent Monnier <monnier.florent@gmail.com>]

Le samedi 01 septembre 2012 16:03:18, Paolo Donadeo a écrit :
> I'm happy to announce the first release of ocaml-lua, the OCaml
> binding of the Lua library. With ocaml-lua you can embed a Lua
> interpreter in an OCaml program in a few lines of code, and use Lua
> for configuration or customization purposes.
> 
> Here are some references:
> 
> The homepage of the project is hosted on OCaml Forge:
> http://ocaml-lua.forge.ocamlcore.org/
> The complete library reference (ocamldoc generated) is here:
> http://ocaml-lua.forge.ocamlcore.org/api-lua/
> Source tarballs are on the download page on OCaml Forge:
> http://forge.ocamlcore.org/frs/?group_id=167
> The official GIT repository is here:
> http://forge.ocamlcore.org/scm/browser.php?group_id=167
> Bug reports and feature requests are on my page on GitHub:
> https://github.com/pdonadeo/ocaml-lua/issues
> 
> I hope it could be useful.

It is useful at least for me ;)
Thanks a lot!

There is a problem with the returned status, and to make ocaml-lua able to be 
compiled with both Lua 5.1.X and 5.2.X,

in Lua 5.1.X there is:

/* thread status; 0 is OK */
#define LUA_YIELD       1
#define LUA_ERRRUN      2
#define LUA_ERRSYNTAX   3
#define LUA_ERRMEM      4
#define LUA_ERRERR      5


in Lua 5.2.X there is:

/* thread status */
#define LUA_OK          0
#define LUA_YIELD       1
#define LUA_ERRRUN      2
#define LUA_ERRSYNTAX   3
#define LUA_ERRMEM      4
#define LUA_ERRGCMM     5
#define LUA_ERRERR      6


and in ocaml-lua there is:

let thread_status_of_int = function
  | 0 -> LUA_OK
  | 1 -> LUA_YIELD
  | 2 -> LUA_ERRRUN
  | 3 -> LUA_ERRSYNTAX
  | 4 -> LUA_ERRMEM
  | 5 -> LUA_ERRERR
  | _ -> failwith "thread_status_of_int: unknown status value"


I asked to join the project but I didn't commit anything because I don't know 
how to fix this kind of translations.

I've found this kind of mismatch in other ocaml bindings when the real values 
are used instead of the symbolic names, but it seems that this kind of code is 
written for performance purpose.

In my own projects I always use a switch to convert from C to ocaml, and an 
array in the other direction, as in:
http://www.linux-nantes.org/%7Efmonnier/ocaml/ocaml-wrapping-c.php#ref_enums


So my question is, what is the better way to handle this kind of problems with 
this kind of translations ?


And even with the other method (switch/array), we can use the C preprocessor 
on the C side, and add a default at the end of the switch, but what is the 
recommended method for the OCaml side ? If there is an additional value for 
the enum, should we include it or not when compiled with the older version of 
the API ? (and raise an exception). Or generate different variants to reflect 
the API at compiled time ?


-- 
Best Regards
Florent