 |
lua-l archive |
|
|
||
|
On 21 Feb 2013 17:51, "James Graves" <james.c.graves.jr@gmail.com> wrote:
>
> steve donovan <steve.j.donovan@gmail.com> wrote:
> >
> > On Thu, Feb 21, 2013 at 4:10 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> > > This all made me think that if Lua had a macro processor, turning a
> > > table into pre-defined locals would be pretty trivial. Something like:
> >
> > There have been suggestions about e.g. 'import sin,cos from math' but
> > the feeling is that this is just sugar, and sugar is bad for you ;)
> >
> > BTW, many of the 'nice-to-have' features that don't get into Lua have
> > ended up in Moonscript, which has this very statement and feels good
> > to use.
>
>
> I'm currently liking the way Go [1] does imports, where the package
> name is retained. For example, you may need the cosine function in
> the math package. So you'll have an import statement:
>
> import {
> "math"
> }
>
> And then you'll normally refer to the function as 'math.Cos' after
> that in this file, though you have options to rename the package or
> import everything from 'math' into the local namespace.
>
> At any rate, the normal import block at the top of each file is short
> and to the point. Also, when reading Go code, if you see 'foo.bar',
> you can just look for 'foo' at the top of the file to see where it
> came from. There is no mystery, and no disturbance to the global
> namespace. Yes, it is a little verbose in the regular program text
> (because you normally see 'math.Cos' instead of just 'Cos'), but I
> think the reduction in ambiguity is worth it.
>
> And this roughly corresponds to how I normally use modules with Lua.
> For example:
>
> local os = require 'os'
> os.exec('ls /tmp')
>
> ------------------------
>
> For various reasons I'm not likely to be switching to Moonscript in
> the near future. :-/
>
> So, my main question is: Is there any way to have some kind of import
> statement (for regular Lua) that doesn't require passing in the
> current _ENV value? Where I just have this:
>
> import 'foo.bar'
>
> and have a table named 'bar' in the local environment (not global).
>
No.
local bar = require "foo.bar"
Is the shortest version. Without macros there is no other option as locals are syntactic (for good reasons). But without ability to rename on import you may as well use globals!
Justin