[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] GSL Shell 2.0 beta1 release
- From: Mike Pall <mikelu-1111@...>
- Date: Thu, 3 Nov 2011 17:20:05 +0100
Roberto Ierusalimschy wrote:
> > Well, what I've done is to reimplement the quadrature routine in pure
> > Lua using the FFI interface.
>
> Small correction: if you use the FFI interface, clearly it is not "pure
> Lua".
Of course it's pure Lua -- the FFI interface is a library. Would
you say that the use of LuaSocket or LPEG libraries makes an
application no longer a pure Lua application? Even if the author
only wrote Lua code himself and is just distributing a bundle of
Lua files?
As you've repeated so often, the point of Lua is to be extended
with libraries and that's why the Lua core is kept so small. Which
coincidentally means one simply cannot write much of anything
_without_ using extra libraries. Confining the definition of a
pure Lua application just to that is a useless proposition.
For me, a pure Lua application is an application that consists
primarily of files written in Lua, which in turn make use of
various common Lua libraries (written in C or Lua). Note that even
the Lua libraries that are packaged with the core are written in C
and make use of libc/libm, which are of course written in C, too.
There is no Lua without C libraries.
IMHO the border to a mixed application is crossed when one or more
of these libraries are made solely for this one application or
when you're _embedding_ Lua into a larger C/C++ codebase.
If you have any doubt about this definition, then have a look at
other language communities: just because you happen to use a
couple of C libraries from PyPI, CPAN or RubyGems, doesn't mean
it's no longer considered a pure Python, Perl or Ruby application.
The boundary between libraries shipped with the core and extra
libraries does not make for a useful distinction.
--Mike