Re: risks of lua fork?

[David Given <dg@...>]

Enrico Tassi wrote:
[...]
> The only thing I'd like to see is some sort of cooperation in the
> production of libraries. AFAIK there are multiple implementation of the
> same libraries (we have 3 different curl bindings for example) and 
> some really important libraries (like posix) seem not to be well
> maintained. This coordination effort has to be made by the community, if
> we failed so far it not a lua fault.

There's currently no real distinction being made between Lua the 
language and Lua the platform. As the maintainers are only really 
concerned with the former, the latter hasn't seen much work, as you'd 
expect... there are projects like LuaX or LuaBinaries, but they've never 
achieved critical mass.

Another thing that's worth considering is that due to the nature of Lua, 
standard distributions are of limited worth. The thing is that as soon 
as you start patching the language, precompiled addons become worthless. 
I've just added the LNUM patch to WordGrinder, in an attempt to improve 
performance. This means that I can no longer use Debian's standard Lua, 
or Debian's standard LuaFileSystem package, and have to start 
distributing, compiling and maintaining my own copies of the language. 
(The binary size has shot up from 16kB to a staggeringly huge 130kB. How 
will we ever cope?)

[...]
> > - bitwise operators (this is a core feature, not a library feature: just
> > try to imagine using arithmetic operators as a library)
>
> What you may want is the possibility of defining a new syntax that
> interprets a | b and bit.or(a,b)... metalua is there. All non necessary
> stuff should stay away from the core, that is a key point of lua I
> think.

Actually, there's a patch that does this:

http://lua-users.org/files/wiki_insecure/power_patches/5.1/newluaoperators.patch

--
David Given
dg@cowlark.com