> Roberto wrote:
> > 1) we should add a "loadlib" facility to the "core" of Lua.
> > This is non-ANSI C, so its inclusion should be controled
> > by a simple define in the makefile. This function must be
> > in the core (like `require'), to enable an out-of-the-box
> > Lua instalation to use any external libraries without
> > recompilation.
> Sure, this is reasonable. The new facility will be an
> "opt-in" option and
> not bother people who can't use it or don't want it.
> However, like a few
> other people, I think a Pandora's box is being opened-- just a slit.
I have to say I agree with John. Reuben has also pointed out that a lot of
the extensions mentioned are non-ANSI. I think the core Lua distribution
should pretty much stay as it is (with revised libraries soon). It should
all remain ANSI and portable.
I like Reubens idea of an enhanced distribution of Lua, which could contain
the non-ANSI stuff (whether it contains a wacky Lua build system or not).
John suggested calling it a different name and I think this is very
practical. Lets call it, say, LuaX, eg. Lua-extensions or Lua-extended. This
build could contain the loadlib code, maybe some libraries, makefiles
building it all etc.
The advantage of this is that pure Lua is simple, and compiles and can be
embedded, to provide Lua in its purest form. No complications, no frills, no
distractions, portable, easy for beginners. Personally I dont want to get
into a situation where I'm actually _removing_ stuff from the default Lua
package when I'm embedding, as currently its usually straight out of the box
and get on with it. Brilliant, its why I gave up the ghost on embedding
Python despite really liking the language. It should still compile into a
command line executable "lua".
Any non-ANSI, non portable, or non vital material goes in LuaX which will
have to be updated and patched far more than Lua as incompatible platform,
OS and library problems emerge, or new features are requested. I can see
releases of this occuring monthly or even weekly. This package may also be
managed by the lua-user community allowing the languages authors to continue
their development of Lua, remaining focussed. This way you have 2 distinct
discussions: Lua the language and LuaX the development environment. This
also doesnt stop competiting solutions for extensions as was suggested by
someone else. This executable with necessary code combined is "luax". Kind
of rolls off the tongue :^)
> someone else. This executable with necessary code combined is "luax". Kind
> of rolls off the tongue :^)
How about "Lax"? Sums up the spirit too!
C++, n. an octopus made by nailing extra legs onto a dog (Anon)
> > someone else. This executable with necessary code combined
> is "luax". Kind
> > of rolls off the tongue :^)
> How about "Lax"? Sums up the spirit too!
How about "laxitive", then we might get moving on it :o)
>> Each addition adds complexity even if well designed
>Not true: unification of global and table methods and the removal of
upvalues are simplifications (the latter not perhaps at the implementation
level, but certainly at the language level).
Yes, lets see Lua stick to its objectives:
Smaller, faster, leaner, cleaner, simple, powerful.
N (my optimised name ;-)
> John suggested calling it a different name and I think this
> is very practical. Lets call it, say, LuaX, eg. Lua-extensions
> or Lua-extended.
I was thinking that it be named separate from Lua. After all, we don't call
automobiles "combustion-engine-X's". It would be nice if the new thing
could fly on its own merit, not powered by the name Lua. On the other hand
there is Common Lisp to Lisp and such.
Also, the person or persons doing the hard work should get to name it. I
don't buy into the "community development" idea... I haven't seen anything
significant get on its feet that way (as opposed to a community improving
something that already exists).