Re: [ANN] GSL Shell 2.0 beta1 release

[Duncan Cross <duncan.cross@...>]

On Fri, Nov 4, 2011 at 1:18 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> Sorry, but it is *trivial* to draw the line here. 'ffi' is a built-in
> module in LuaJIT, not in Lua.

Well... what about the 'bit' library? Ignoring 5.2 and bit32 for the
moment, and pretending only 5.1 exists - LuaJIT has 'bit' built-in
like FFI, but there is also an equivalent C module for standard Lua
5.1 - and there are *also* implementations of 'bit' functionality
based purely on the standard math functions etc. out there (slow, but
it works). A module or program that imports "bit" should not need to
know which of those things is being imported, just that whatever it is
it implements the same interface. I have to admit I would find it
weird to not consider such a module or program "pure Lua".

See, I do think there is a worthwhile distinction to be made between:
- a module/program that consists solely of plaintext code that the
standard Lua compiler will accept, and
- a module/program that is (wholly or partly) written in C
...regardless of whether it *depends* on modules that are not part of
the standard Lua set. And whether you want to call this distinction
"pure Lua" vs. "non-pure Lua", or attempt to reserve those terms for
standard-modules-only Lua code seems to me to be mostly a matter of
taste. (Unfortunately. I like things to be clear and consistently
understood, too.)

I suppose it might ultimately all come back to the ambiguity of what
"Lua" means, whether we mean Lua-the-language or Lua-the-C-library.
Writing "language-portable" code means writing code that runs on the
standard Lua executable, but also in Kahlua or Lua.NET or Lua-Alchemy
or a restricted sandboxed Lua environment where you don't have the
option of loading up arbitrary DLLs/SOs. The language-portable code
should be able to be agnostic about the implementation of its
dependencies, as long as the package provides an equivalent interface
- for example, a game may provide its own socket-handling API, but you
might be able to implement an equivalent to the LuaSocket interface on
top of this, and then you can reuse language-portable code that
expects LuaSocket. This is distinct from "C-portable" Lua modules that
can certainly be compiled everywhere that C code can be compiled, but
not necessarily run everywhere that Lua code can be run.

-Duncan