lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


[ Sorry Thierry, your reply has quotation levels completely messed at least in my reader.  Some of David's text seems like yours. ]


Anyway.  We're growing up and out of the situation described. There are and there will be both scenarios; Lua as a "distro" language (modules, syntax alternations, but no patches) and the embedded part, where jungle rules apply and one can Rule it All. At least I don't see it as an either-or scenario, at all. Many things that currently need patching will be able (and already are!) to be done without. This is in perfect alignment with the approach of the Lua authors, keeping the core small, simple and fast.

Some main projects worth observing are:

- LuaRocks - currently at 0.2, a metadistro of Lua modules, formulates how to get them to your machine and how to build them if you're a module author

- MetaLua, luaSuper et.al. - front side (token filtering) approaches which give benefits of patching without the burden.


Mapping these to your earlier worries:

Few points need to be addressed or at least discussed soon to build a roadmap and give visibility.
These are not all core features.
- support for Unicode

True. I don't see it requiring core modifications, though.

- richer pattern matching

Enrico mentioned Lpeg and PCRE; seems there's things happening on this front.

- just in time compilation

LuaJIT has gotten rave mentions by those using it; and it will just get better.  I fail to see why LuaJIT should be part of Lua itself, though.

- bitwise operators (this is a core feature, not a library feature: just try to imagine using arithmetic operators as a library)

Partly agreed. I see bitwise operations together with enums ('magic' values often used in C interfaces). There is _one_ core feature that would be required for an efficient implementation of enums in Lua. All else is on the module side, but the users won't really see this.

Then again, I would rather have the enums/bitwise feature internal to the language, as you mentioned. :)   For one it touches the Lua/C API.


- probably 0 indexed array (Lua has resisted to much more disturbing changes…)

:) resistance argument is really void. Sorry. :)

These are being discussed and yes, this level of things do belong in the core language.

- efficient class model
Not addressing some may just alienate part of community which may satisfy narrow embedded core community.



Agreed. Even this is not part of the core, but having it at the level of the "built-in" libraries (string etc. - maybe just call it "class") would give a nice sample reference on how to build classes.

 

So the risks are probably that:
-          Lua interest drops
-          Lua interest is maintained but may escape from original authors to more active maintainers.

 

 

Lua interest is only rising. The focus will move from the PUC authors to the "ring 1" module and syntax mod makers, but that is only natural, and in everyone's interest. We have many rings in the community.

Thanks for bringing your worries up.  Hopefully, we're able to prove them wrong.  :)

-asko




Grellier, Thierry kirjoitti 29.10.2007 kello 16:13:

Would like to add this one in http://www.lua.org/quotes.html ...

"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?)"

The point is that so called embedded lua users are a good excuse not to
do anything to help most of the others (eventually working on embedded
system too!) who'd like to avoid falling in this dilemma. The fact is
that Lua conf shall help really constrained embedded users trimming Lua
to their needs and not discouraging the others. What are the core issues
that make so many people needing to patch Lua despite the cost of it?

-----Original Message-----
Sent: Monday, October 29, 2007 1:51 PM
Subject: Re: risks of lua fork?

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:

rs.patch

-- 
David Given