Re: Suggestion for 5.3: import() for creating a "slew" of locals

[Tom N Harris <telliamed@...>]

On Sunday, November 17, 2013 10:28:26 PM Luiz Henrique de Figueiredo wrote:
> > import(io, 'read', 'write', 'setvbuf')
> 
> If you can assume that such statements happen only within say the first
> 10 lines of the file you could write a reader function that scans these
> lines and does a simple gsub. You can even drop the quotes. Something
> like this:
> 

I don't think that's a safe assumption since I may want to only import values 
into the scope of a function.

An import statement that's only sugar for `local x = x` I think is of limited 
utility. The best justification for importing is to signify to the compiler 
your intent to use the names as aliases for a global.

Right now, assignment to a local is being overloaded with two meanings: to 
create a unique lexically-scoped name, and to alias a global. The second use 
has become common because it is faster than looking up the global value on 
every use. But in a different implementation, such as LuaJIT, looking up a 
global is not as expensive. In that case, aliasing globals as locals only 
creates extra upvalues without much extra speed. If the compiler knew that you 
were only aliasing, it could skip creating the upvalues. Aliases also 
typically do not get reassigned after being created, which can lead to further 
optimizations.

Aliasing adds a feature that can't currently be emulated. Creating local 
variables can't be done at runtime, so the feature can't be added using just a 
function. Thus I think it is reasonable that import be added as a statement.

If in imported name is an alias, then what should happen when an alias is 
assigned to?

1. The reference changed. Then aliases act identically to locals.
2. Assignment is forbidden. Aliases are read-only.
3. The global value is changed. Aliases could be used to emulate 'with' from 
other languages.

I think #3 is the most interesting and adds flexibility to the language. If 
#1, then the import statement becomes nothing more than sugar. #2 I'm not sure 
if it's feasible to implement.

-- 
tom <telliamed@whoopdedo.org>