Re: How close to C do you make your binding?

[William Ahern <william@...>]

On Fri, Jun 20, 2014 at 01:21:40AM +0300, K?? Mykolas wrote:
> In my personal opinion, writing Lua modules too close C level --- is
> just like handycapping Lua developers who are going to use Your
> module(s). If developer wanted as low as C level --- he/she would have
> chosen C instead of Lua. So, basically, Lua tools, ideas and paradigms
> for writing Lua modules. C tools, ideas and paradigms for writing C
> modules.
> 

IMO, good C library code and good Lua library code look very similar,
excepting low-level data structures like hashes, or high-level optimizations
like memoization.

Lua uses iterators heavily. Where C code boxes a set of data, it too should
expose a reentrant iterator. If it does it properly, it's trivial to map
this to Lua.

Lua has the idea of continuations, where you can wrap an abstract operation
implemented functionally within a user-managed container that allows saving
and restoring a state of execution. In C most people either use threads or
callbacks for this, but a C _library_ should never expose threads or
callbacks [which perform non-trivial work] because it shifts a tremendous
burden onto the library, particularly in a language like C without garbage
collection or high-level atomic types, such as synchronized methods in Java.
Such things should be properly contained within the blackbox of the API.
Since C supports state machines so well, there's no excuse not to provide a
restartable interface for jobs which naturally suggest yield and resume
semantics, such parsing, construction, I/O--basically anything which
operates on streams or lists of data in discrete chunks. Again, if it does
this properly it makes Lua bindings a breeze.

A good C library implements RAII in terms of resource management. That
usually resolves to reference counted lifetime management, with a mostly
hierarchical tree of object ownership. This is a natural fit for both Lua
integration and C integration.

Basically, I can't think of many patterns which are fundamentally different
between C and Lua code. They may seem different in terms of syntax and the
mechanics of their implementation, but conceptually they implement the same
abstract logic. Ultimately as a programmer of libraries and modules you want
to want to follow strict, idiomatic, nearly language-neutral habits which
allow users of your interface the flexibility to integrate your code as they
best see fit. For example, whether I expect the user to be using Lua or not,
I don't want to dictate either an event-oriented or thread-oriented
concurrency model.

Ultimately you want modularity, reentrancy, restartability, RAII, iterators,
etc. And you want as many or all of these things simultaneously. That
drastically reduces the solution space to a tiny number of candidate data
structure and algorithm compositions.

So in my opinion, there's nothing about "C level" that makes it a poor fit
for idiomatic Lua patterns. But bad C code, just as bad Lua code, will make
integration and composition a giant headache.