Re: Binary Modules for Lua [was Re: External modules]

[Philippe Lhoste <PhiLho@...>]

On 2002/11/21 19:46:09, Björn De Meyer <bjorn.demeyer@pandora.be> wrote:

> Thatcher Ulrich wrote:
>> 
>> I took the liberty of putting together the bare bones of a Binary
>> Module system for Lua 4.0, based on Ignacio's uselib code.  I put up a
>> page on the wiki, with a source patch and an interpreter binary for
>> Linux (Win32 to come when I get a chance), and a list of ready-to-use
>> modules.  (The list of modules consists of one thing at the moment: a
>> version of luaSDL, which I've made available before in various forms.)
>> 
> /snip
> Hmmmm... not bad... I'm currently trying to get a similar though 
> slightly different idea to work. My idea was to be able to say in 
> Lua:
> 
> libc = loadlib("c");
> malloc = libc:declare("malloc","pointer","int")
> -- declare function takes function name, return value and arguments
> -- and creates an automagical lua wrapper for the raw C function.
> -- using some dirty hacks, I reckon.
> -- I'd like to to support "string","pointer","int", and "double" to
> begin with.
> free = libc:declare("free","void","pointer")
> libc.declare = nil;
> -- From now on, you cannot declare any new functions from 
> -- libc for security reasons.  
> block = malloc(1000)
> free(block)
> -- Of course having a malloc in lua is pointless for now.

That's a different beast, it is like Visual Basic's Declare, allowing to 
call any Windows API functions. VB converts types from VB to C and back.

> The fine point of this would be that you wouldn't need to 
> write a wrappper C library anymore, and that you could call 
> many C functions directly. I don't know whether it's possible, 
> but I want to give it a shot anyway. I think it might work if
> I use some arbitrary limitations on the type and number 
> of the arguments a C function can have...

Well, both are useful and should coexists.
The library approach allows nice Lua wrappers around ugly C functions :-)

Eg. the wrapper can use the Lua capability of several return values to 
avoid using "out" parameters, it can handle tables instead of structures 
or other complex data, etc.

The FFI (foreign function interface) allows a lot of flexibility to the 
end user that doesn't have access to a compiler (and is much faster that 
writing a library). It is at least useful for rarely needed functions, 
that won't worth writing a wrapper around.

For most common tasks (eg. file operations), a library is probably better.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/