Command line library load in Lua 5.2

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Command line library load in Lua 5.2

Dirk Laurie-2
Now that we are all adjusting to the new way of handling modules, the
'-l' command might be extended to allow this:

    lua5.2 -l mymod=long_and_unwieldy_module_name -i

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Command line library load in Lua 5.2

Luiz Henrique de Figueiredo
> Now that we are all adjusting to the new way of handling modules, the
> '-l' command might be extended to allow this:
>
>     lua5.2 -l mymod=long_and_unwieldy_module_name -i

mymod would be a global? ie, that'd be translated to
        mymod = require"long_and_unwieldy_module_name"

In that direction lies a suggestion that modules create globals,
something that has already been beaten to death here (we hope)...

Reply | Threaded
Open this post in threaded view
|

Re: Command line library load in Lua 5.2

Roberto Ierusalimschy
In reply to this post by Dirk Laurie-2
> Now that we are all adjusting to the new way of handling modules, the
> '-l' command might be extended to allow this:
>
>     lua5.2 -l mymod=long_and_unwieldy_module_name -i

It may not be the shortest way to write it, but you can use the following:

$ lua5.2 -l long_and_unwieldy_module_name -e 'mymod=long_and_unwieldy_module_name' -i

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Command line library load in Lua 5.2

Dirk Laurie-2
In reply to this post by Luiz Henrique de Figueiredo
2011/11/1 Luiz Henrique de Figueiredo <[hidden email]>:

>> Now that we are all adjusting to the new way of handling modules, the
>> '-l' command might be extended to allow this:
>>
>>     lua5.2 -l mymod=long_and_unwieldy_module_name -i
>
> mymod would be a global? ie, that'd be translated to
>        mymod = require"long_and_unwieldy_module_name"
>
> In that direction lies a suggestion that modules create globals,
> something that has already been beaten to death here (we hope)...
>

On the contrary, my point is precisely that all the new good habits of
avoiding pollution of the global namespace is undermined by the Lua5.2
interpreter itself.

The present behaviour is this:

~~~~ mymod.lua
return 42
~~~~

    $ lua5.1 -l mymod -e "print(mymod)"
nil

    $ lua5.2 -l mymod -e "print(mymod)"
42

I.e. the global name is not created by the module, but by the Lua5.2
standalone interpreter.

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Command line library load in Lua 5.2

Roberto Ierusalimschy
> On the contrary, my point is precisely that all the new good habits of
> avoiding pollution of the global namespace is undermined by the Lua5.2
> interpreter itself.
>
> The present behaviour is this:
>
> ~~~~ mymod.lua
> return 42
> ~~~~
>
>     $ lua5.1 -l mymod -e "print(mymod)"
> nil
>
>     $ lua5.2 -l mymod -e "print(mymod)"
> 42
>
> I.e. the global name is not created by the module, but by the Lua5.2
> standalone interpreter.

Option '-l' would be essentially useless if it did not create the
global. It is intended to be used in interative mode and with the -e
option:

  $ lua5.2 -l mymod -e "print(mymod.foo(10))"

Not polluting the global namespace does not mean a complete prohibition
of ever creating a global.

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: Command line library load in Lua 5.2

David Manura
On Wed, Nov 2, 2011 at 1:54 PM, Roberto Ierusalimschy
<[hidden email]> wrote:
> Option '-l' would be essentially useless if it did not create the global
> It is intended to be used in interative mode and with the -e option:
>  $ lua5.2 -l mymod -e "print(mymod.foo(10))"
> Not polluting the global namespace does not mean a complete prohibition
> of ever creating a global.

-l is intended (and only partly successful) as a shorthand.  However,
I suspect the more important design limitation may be that there is
not a non-debug way to set _ENV from the command-line before entering
interactive mode.  This does not work as intended:

  lua5.2 -e "_ENV=require'myenv'" -i

The lesser concern is what the shorthand for that may be, which
according to the OP's suggestion could be roughly like

  lua5.2 -l_ENV=myenv -i

We may benefit rather from some shorthand for forms like this though:

  lua5.2 -e "_ENV=require'x'(y)" -i

For instance,

  lua5.2 -e "_ENV=require'ziploader'('foo.zip:foo.bar.baz;qux.zip:qux.bar.corge')"
-i

which will load the module "ziploader", which then loads the module
"foo/bar/baz.lua" from the file "foo.zip", loads the module
"qux/bar/corge.lua" from "qux.zip", stores both of these in some way
of its own choosing in a table with an __index metamethod to _G, and
assigns that to _ENV.  Moreover, other modules require'd by the
interpreter are unaffected by this _ENV.

A possible shorthand is

  lua5.2 -Eziploader='foo.zip:foo.bar.baz;qux.zip:qux.bar.corge' -i

Reply | Threaded
Open this post in threaded view
|

Fwd: Command line library load in Lua 5.2

Dirk Laurie-2
In reply to this post by Roberto Ierusalimschy
>> I.e. the global name is not created by the module, but by the Lua5.2
>> standalone interpreter.
>
> Option '-l' would be essentially useless if it did not create the
> global.   It is intended to be used in interative mode and with the -e
> option: $ lua5.2 -l mymod -e "print(mymod.foo(10))"

I'll grant that the global is useful in that context.

But '-l' is not useless without the global.  Lua 5.1 does not set it.
Yet nothing forces you to use only modules that set globals 5.1-style.
 It's perfectly OK to use modules that return tables 5.2-style.  Just
say `local mymod=require "mymod"`.  This works nicely with '-l',
because:

* option `-l` adds an item to package.loaded
* `local mymod = require "mymod"` in the program picks up the module
loaded with `-l` instead invoking the package search mechanism.

The original proposal did not spell out that `-l
mymod=mymod_123_alpha_rc3` creates or replaces an entry in
package.loaded for `mymod` rather than for `mymod_123_alpha_rc3`, but
preloading a specific version of a required package would be a useful
application for it.

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Command line library load in Lua 5.2

Matthew Wild
On 3 November 2011 09:45, Dirk Laurie <[hidden email]> wrote:

>>> I.e. the global name is not created by the module, but by the Lua5.2
>>> standalone interpreter.
>>
>> Option '-l' would be essentially useless if it did not create the
>> global.   It is intended to be used in interative mode and with the -e
>> option: $ lua5.2 -l mymod -e "print(mymod.foo(10))"
>
> I'll grant that the global is useful in that context.
>
> But '-l' is not useless without the global.  Lua 5.1 does not set it.
> Yet nothing forces you to use only modules that set globals 5.1-style.
>  It's perfectly OK to use modules that return tables 5.2-style.  Just
> say `local mymod=require "mymod"`.  This works nicely with '-l',
> because:
>
> * option `-l` adds an item to package.loaded
> * `local mymod = require "mymod"` in the program picks up the module
> loaded with `-l` instead invoking the package search mechanism.
>

I'm confused... if you're going to use require(), that also sets
package.loaded if not already set. So... how is -l useful if you have
to call require right after anyway?

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Command line library load in Lua 5.2

Dirk Laurie-2
2011/11/3 Matthew Wild <[hidden email]>:
>
> I'm confused... if you're going to use require(), that also sets
> package.loaded if not already set. So... how is -l useful if you have
> to call require right after anyway?
>

Don't think of '-l' as being merely convenient.  Think of it as
providing command-line control over loading of modules.

For example: the program has:

mod1 = require "mod1"
mod2 = require "mod2"
mod3 = require "mod3"

mod12 = require "mod12"

These modules are supposed to be independent of each other, but the
program has an obscure bug.  You suspect that one of these modules is
setting a global which affects one of the others.  Without any need to
edit the source (which may have been supplied to you as bytecode) you
can do this:

   $ lua -l mod4 prog.lua

Now "mod4" gets loaded first.

And this sort of application is why I'm pushing for extending the
syntax of '-l' to allow

  $ lua -l mod4=mod4_patched prog.lua

That would allow '-l' to achieve command-line templating.

Dirk