RE: Zoom out - LuaX

[Nick Trout <Nick.Trout@...>]

> 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 :^)

Regards,
Nick