Browse thread
Binding the Lua library [was: adding a scripting language to an ocaml program]
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2010-07-05 (22:32) |
From: | Paolo Donadeo <p.donadeo@g...> |
Subject: | Binding the Lua library [was: adding a scripting language to an ocaml program] |
Some time ago I started to write an OCaml binding to the Lua API library [1] and the so called auxiliary library [2]. My objective was a tool to give the user of an application (in this case a web application) the power to extend the application with plugins in a simple and safe environment. I choose Lua because I don't want to compel my user to learn a relatively difficult language like OCaml, nor an esoteric one like Scheme. The user, in the setting I have in mind, is supposed to be strange to programming languages. Moreover Lua is a beautiful language, Scheme inspired, and the model of its development is very similar to OCaml (academic and "cathedral", but open to the community). And Lua has been designed from its start to be an extension language, it's *very* easy to sandbox it. So I wrote the binding to some basic functions and a stress test designed to reveal memory leaks of the binding. The test passed and so I consider the code quite stable, but I had to stop the development due to the chronic lack of time and due to a specific problem: I don't know how to handle the impedance mismatch between the two garbage collectors. Lua has the concept of "userdata": from the C side you can create opaque values (malloc allocated void* objects) along with the operations (C functions conforming a specific typedef) to handle those. It's easy to push the userdatum and its operations on the stack of the Lua state and build an object (a Lua table, similar to a Javascript object). The Lua program can use the object and call methods. This is the way libraries like LuaSocket [3] are written. In an ideal world one want to define an OCaml type, create values of that type and operations on it, push everything on the stack and the use it from the Lua side. But what happen when the Lua GC decide to collect the userdatum? If a "metamethod" __gc is provided (ideally an OCaml function) the Lua state calls it before deallocating the object. But that object could be still alive for the OCaml GC, so what is the standard way (if any) to handle these situations? And again: how to translate (read: how to bind) in OCaml functions like these: void *lua_newuserdata (lua_State *L, size_t size); [4] or void *lua_touserdata (lua_State *L, int index); [5] Is Obj.magic the only possible way? It's ugly and, of course, "Obj.magic is not part of the OCaml language", but in this case you use a cast in C, so why not cast a spell in OCaml? If anyone is interested in my prototype I could clean up the source, remove comments in Italian and publish it on GitHub or OCamlCore. And, of course, any ideas or help on the garbage collector(s) issue are welcome. [1] http://www.lua.org/manual/5.1/manual.html#3 [2] http://www.lua.org/manual/5.1/manual.html#4 [3] http://w3.impa.br/~diego/software/luasocket/ [4] http://www.lua.org/manual/5.1/manual.html#lua_newuserdata [5] http://www.lua.org/manual/5.1/manual.html#lua_touserdata -- Paolo ~ ~ :wq