[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Suggestion for 5.3: import() for creating a "slew" of locals
- From: Andrew Starks <andrew.starks@...>
- Date: Sun, 17 Nov 2013 19:36:31 -0600
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
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
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
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.
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:
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. :)