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

[Andrew Starks <andrew.starks@...>]

On Sunday, November 17, 2013, Tom N Harris  wrote:
> 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>

I think that it should be limited to the beginning, honoring the convention that definitions and general nuttiness be contained in the introduction. 

Consider that the table notation makes fields into upvalues in the same way that these suggestions do. So adding something on the call-side means turning something that's no work:

Myfunc(t)

Work into something that requires a "super in" operator. 

I get that there are many places where something like this could be used, but this is kind of stuff is risky and if it goes badly them BAM! You've got Ruby!

Really, there are four parts to this:

1: a sugary treat that is limited to a augment of the parser (or made in a quick preprocessor macro, written in LPEG of course) to make things clear and succinct or terse and obscure. (The macro I. LPEG sounds awesome, to me...)

2. A library addition that could easily be made as a regular library so why bother?

3. A change to the language, which is extremely dangerous and should be thought about in a context of extremely broad use cases...

4. I hope this thread ends before it hits 25 posts.  :)