Why Lua?

Post by haberman » Wed, Feb 01, 2012, 12:48 AM UTC

sshumaker wrote: post #32

haberman wrote: post #14

The more I learn about Lua's design and implementation, the more impressed I am. It's very rare to see software that does so much with so little code. The design is extremely clean and the code is extremely fast. The C API is easy to use and gives good performance, and yet encapsulates enough of the VM's implementation that C modules are source and binary compatible with both Lua and LuaJIT, two very different implem…

Lua has great C integration, but LuaJIT's is even better. You can natively interface with C code without a recompile, just by defining the C function prototype in Lua, and using it like you would any normal lua function. Better still, LuaJIT can frequently inline the calls to C code, so there's no cross-language marshaling penalty. Check out http://luajit.org/ext_ffi_tutorial.html

Post by sshumaker » Wed, Feb 01, 2012, 12:59 AM UTC

whatajoke wrote: post #49

Not criicizing lua, but worth comparing to guile. > Integration with C (and C++ for that matter) Guile does it better. You can use shared memory threads in guile without any penalty. Atmost you have to allow for the garbage collector to run when inside FFI functions. But that is a small price to pay in case you need to use multiple parallel-concurrent threads with a single heap. Guile was built with FFI in mind and h…

  (define memcpy
	       (let ((this (dynamic-link)))
	         (pointer->procedure '*
	                             (dynamic-func "memcpy" this)
	                             (list '* '* size_t))))

  ffi.cdef [[
	void * memcpy ( void * destination, const void * source, size_t num );
  ]]

Post by sshumaker » Wed, Feb 01, 2012, 1:03 AM UTC

haberman wrote: post #51

sshumaker wrote: post #32

Earlier quoted context omitted.

Lua has great C integration, but LuaJIT's is even better. You can natively interface with C code without a recompile, just by defining the C function prototype in Lua, and using it like you would any normal lua function. Better still, LuaJIT can frequently inline the calls to C code, so there's no cross-language marshaling penalty. Check out http://luajit.org/ext_ffi_tutorial.html

FFI is extremely cool and impressive, no doubt, but a major downside of it is that you give up memory safety. Once you import it your Lua program can SEGV the interpreter and read/write arbitrary memory in your process. Freedom from memory errors is a major motivation for using high-level languages, so this should not be given up lightly. Also, from a security standpoint it means your Lua is less sandboxed.

Post by sshumaker » Wed, Feb 01, 2012, 1:12 AM UTC

hythloday wrote: post #42

sshumaker wrote: post #36

Earlier quoted context omitted.

__index and __newindex are the key ones - effectively equivalent to method_missing in Ruby. __index gets called if you try to read a non-existent key, and __newindex gets called if you try to write to a non-existing key. You can use these methods to implement inheritance, proxies, getters/setters, all sorts of stuff.

This sounds very much like Python's __getattribute__ [0] method. Is there a difference I'm not understanding? [0] http://docs.python.org/reference/datamodel.html#object.__get...

Post by haberman » Wed, Feb 01, 2012, 1:13 AM UTC

whatajoke wrote: post #49

Not criicizing lua, but worth comparing to guile. > Integration with C (and C++ for that matter) Guile does it better. You can use shared memory threads in guile without any penalty. Atmost you have to allow for the garbage collector to run when inside FFI functions. But that is a small price to pay in case you need to use multiple parallel-concurrent threads with a single heap. Guile was built with FFI in mind and h…