Re: Zoom out

["John Belmonte" <jvb@...>]

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.

This is hyperbole, but let's say that one day the Lua distribution contained
all the functionality of the Python distribution.  Of course some of the
Python language facilities and most of the Python libraries can't be
provided on top of ANSI C, so at this point about 97% of the Lua
distribution is "opt-in".  The Lua purists would still be happy, if it
weren't for the fact that 97% of the lua-l traffic now reflects the non-ANSI
part also.  Likewise for lua-users.org.

I'm not suggesting that the Lua authors would let that happen.  However, as
a practical example, consider that right now Lua has no enforced facility
for "modules" (here meaning how they are used, not how they are linked).
There are a least a couple ways to go about modules in 4.0, and even more in
4.1 due to the fact that it properly generates global table events for
global accesses.  Yet the addition of the loadlib facility is going to
create pressure for a standard, as you hint:

> 3) on top of that, libraries should use some form of
> modules (all public functions in a table, for instance) to
> control name-space polution. There is no need that all
> libraries use the same scheme (altough it would be
> desirable).

Replying  to Jim Mathies, Roberto also wrote:

> > Loadlib, the aux libs, iolib, 3rd party libraries in general..
> > all of these should be placed outside the standard Lua
> > distribution and supplied as separate downloads.
>
> I mostly agree. But loadlib is different: it is very small, and
> it gives a big help in the distribution of separate downloads
> (because then you do not need to recompile Lua to install
> these 3rd party libraries).

Right, except that loadlib does not have to be in the Lua distribution to
have this benefit.  The thing that takes Lua and adds loadlib, *that* would
be the package that people would not need to recompile to install 3rd party
libraries.  Even though the net result of this new package is identical, it
represents a big psychological difference.  When a module standard has to be
hammered out-- and everything else that is sure to follow-- there is now a
proper place for it to happen.

--John