Re: Literal mimicking of C APIs in Lua (split from Re: [ANN] luaposix 33.3.0 released)

[Sean Conner <sean@...>]

It was thus said that the Great Gary V. Vaughan once stated:
> Hi Sean,
> 
> > On Mar 1, 2015, at 4:16 AM, Sean Conner <sean@conman.org> wrote:
> > 
> > It was thus said that the Great Gary V. Vaughan once stated:
> >> A library binding various POSIX APIs, including curses. POSIX is the IEEE
> >> Portable Operating System Interface standard. luaposix is based on lposix
> >> and lcurses.
> >> 
> >> I am happy to announce release 33.3.0 of luaposix.
> > 
> >  This isn't about luaposix per se, but this is prompting this observation
> > about Lua wrappers for C APIs: they tend to mimic it quite literally (to the
> > point where I think I've said this before: if I wanted to code in C, I know
> > where to find it).
> 
> It's precisely because I don't want to code in C either that the low-level API
> of luaposix aspires to be as thin a wrapper for the C API as possible.  It's
> easier, faster and less error-prone to write the Luaish API on top of the thin
> C wrappers in Lua than it is to write the fancy stuff in C.
> 
> Not only that, this leaves the door open to replace the C bindings with an FFI
> binding that the Luaish layer can equally sit on top of and ultimately shipping
> no C code at all in luaposix... as long as a dependency on LuaJIT and/or LuaFFI
> is an acceptable compromise.  When the low-level C code implements the user-
> facing API, all of this is a lot more difficult.

  So far, this is the best explaination I've seen, but it's not without
problems.  Notably, from the LuaJIT FFI documentation [1]:

	C declarations are not passed through a C pre-processor, yet. No
	pre-processor tokens are allowed, except for #pragma pack. Replace
	#define in existing C header files with enum, static const or
	typedef and/or pass the files through an external C pre-processor
	(once). Be careful not to include unneeded or redundant declarations
	from unrelated header files.

While this isn't that bad for syslog(), as the constants are (for modern
systems in use today) the same across the board (RFC-3164) and even the
options for openlog() (like LOG_PID and LOG_PERROR) are probably the same,
so they can be hardcoded in Lua:

	LOG_USER = 8
	LOG_MAIL = 16 -- etc

	LOG_EMERG = 0
	LOG_ALERT = 1 -- etc

	LOG_PID = 1
	LOG_CONS = 2
	LOG_ODELAY = 4 -- etc

But then you get to something like signal().  Not only can, say, SIGURG,
vary from operating system to operating system, but it can vary on the same
operating system (Linux, depending upon the architecture, will define SIGURG
as 23, 16, 21 or 29) and certainly makes writing Lua-only code (using FFI) a
challenge.  There is Alien [2], which includes a tool to extract magic
numbers from header files that could help with this.  But you still have the
issue of managing different operating systems (and architectures).

  I did, however, try your approach with syslog(), and I do have to admit it
was easier to write than trying to write Lua in C (my previous approach).  I
may have to experiment a bit more with this approach.

  -spc

[1]	http://luajit.org/ext_ffi_api.html

[2]	http://alien.luaforge.net/