require etc (was Re: globals (_locals))

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

Renato Cerqueira wrote:
> For large projects, I use almost the same solution that Roberto
> describes in his LTN. But, in general, I have to adapt it for the
particular
> requirements of each project. I like this kind of flexibility.
> (BTW, when I don't want flexibility, I use C or C++).

(I'm presuming Renato's comment was about modules, not globals.)

I'm tending to think the same way these days.  I view Lua as second-to-none
in the areas of configuration and embedded scripting.  As a "system"
scripting language however, compared to solutions like Python or Perl, it
falls short.  This is not a negative view of Lua-- I don't think one
solution could cover all these areas perfectly.  Anyway I'm not looking for
something to replace Python for general scripting on my PC.  On the other
hand Lua has opened up new windows for small apps on big and small systems,
what Python and the rest could never do.

Trying to stretch Lua to become a competitive system scripting language may
be a mistake.  (I'm not criticizing the Lua authors.  They understood where
their language fits way before I even knew what Lua was.  Some users, on the
other hand, may be trying too hard to use Lua for anything and everything.)
When Lua is inside another app, as Renato says, it's often necessary to
adapt to the requirements of the project.  Python and Perl don't have these
constraints.  They, along with their supporting modules, are on the
"outside" and force apps to adapt to their requirements.

As an example take the "require" function, on-deck for the next release.  I
think it will be a good example of how to implement module loading.  I don't
think it will be something that will suddenly allow us all to trade Lua
modules.  You'll notice that require takes a file name, not a module name.
So if you're writing some module "vector" that uses another module
"mathstuff", you'll write

    require("mathstuff.lua")

However some project that uses the vector module may implement automatic
pre-compiling (like Python does with py and pyc files).  So ".lua" may not
be the correct extension.  Or the app might be on a mini-os that doesn't
support filename extensions at all.  Yes, you can imagine redefining
require() to your project needs to work around this.  The point is that
these issues exist in infinite variations for embedded scripting.  Even more
than the module system implementation, this problem exists with the module
contents itself.  Trying to stretch Lua in such areas looks futile to me.

-John