lua-users home
lua-l archive

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

On Jan 7, 2008 6:59 PM, Jerome Vuarand <> wrote:
> Andre Carregal wrote:
> > In fact, if there is one thing I'd like to see in Lua 5.2 that would
> > be a better way to handle the module finding part of require(). Tools
> > that want to intercept require() calls have to repeat a lot of work
> > today and any improvements on this front would be welcome.
> What kind of require() interception does require so much code ? Can you
> give us an example of 'interceptor' code you would like to be able to
> write in an hypothetically ideal module system ?

It's not about how much code one need to write to intercept require,
but about how many times that code has to be written. :o)

The point is that tools that want to preprocess Lua source files
usually have to redefine a common set of functions (loadstring,
loadfile, dostring, dofile, require) in order to do that. While the
load* and do* functions are trivial to redefine, require is more
subtle since it involves both a search and the load itself.

One option would be to make the C loadfile function check for a Lua
loadstring function and use it if present. So if one simply redefined
loadstring, the other functions (loadfile, dostring, dofile and
require) would also use this filter. While I'd vote for this option,
it could mean a change in the current semantics for those 4 functions.

> You can find an example of a module loader that reimplements the normal
> Lua modules loader in pure Lua on the wiki [1]. It's just 22 lines long
> (is that a lot ?). Rewriting require in pure Lua to better suit your
> needs wouldn't be more complicated.
> [1]

I understand that writing a loader is simple, but again my point is
that writing a require filter could be easier than it is now, maybe
even as easy as writing a loadstring filter.