for loop variables not recognized upon assignment

[nilnor]

I noticed that for loop variables are not recognized as being locals when they are the target of assignments.

To illustrate, the following moonscript:

for k,v in ipairs t
  v = v .. 'foo'

Transpiles down to:

for k, v in ipairs(t) do
  local v = v .. 'foo'
end

When I would have expected the following Lua output:

for k, v in ipairs(t) do
  v = v .. 'foo'
end

[nilnor]

Now I notice that the original problem might not be apparent from the shortened down snippet above. In my real-world case I had:

v = 'some op' if expression

which then ended up:

if expression then
  local v = 'some op'
end

meaning that the assignment was lost.

[leafo]

The way it works is intentional. I wanted to preserve block level scoping.

You could rewrite what you are trying to do like this:

v = if expression then 'some op'

An alternative implementation could hoist all the local definitions to the top of the nearest function but I don't know if I like that. Thoughts?

[etandel]

If I may sneak into this issue, IMHO this is one of those things that happen with local by default. While

var ='some op' if condition

is just syntatic sugar for

if condition
  var = 'some op'

(and in fact both have the same behavior inside a for loop), this behavior is inconsistent when comparing 'for' and other scopes.
This code:

for k,v in pairs {'hello', 'world'}
    v = 'goodbye' if true
    print v

print '----'
if true
    v = 'hello\nworld'
    v = 'goodbye' if true
    print v

print '----'
f = ->
    v = 'hello'
    (->
        v = 'goodbye' if true)!
    print v
f!

print '----'
class Test
    a: 'a'
f = ->
    v = 'hello\nworld'
    with Test!
        v = 'goodbye' if true
    print v
f!

Generates this output:

hello
world
----
goodbye
----
goodbye
----
goodbye

[leafo]

Ah true, the for loop is inconsistent, it should be aware of the variables brought into scope by the loop. I've corrected it.

[nilnor]

Great, thanks! And thanks @etandel for providing the examples.

[zah]

Isn't this behaviour a bit confusing?

v = 10 if true
print v

My intuition is that most people will expect the value to be printed here.

[leafo]

Hmm. I could make it so when you use line decorator statements, if there is an assignment it is hoisted outside of the one line scope that is created. Thoughts?

[etandel]

I'd rather have a keyword to declare variables. I have introduced bugs doing things like:

if cond
    myvar = 1
else
    myvar = 2

 do_stuff myvar

wich doesn't work because 'myvar' ends up created inside the 'if' block and thus has the value of 'nil' when do_stuff gets called.

To fix this I do some useless assignment befor the if such as

myvar = nil

or

myvar = ''

but I think this is quite ugly. I'd prefer a keyword like 'local' or 'var':

local myvar
if cond
    myvar = 1
else
    myvar = 2

[leafo]

Bringing back local is definitely on my todo list (the current alternative is to do x = nil)

But, to address your specific example, I would write this:

myvar = if cond
  1
else
  2

Which compiles to what you want to write: http://moonscript.org/compiler/#v

[nilnor]

Hmm. I could make it so when you use line decorator statements, if there is an assignment it is hoisted outside of the one line scope that is created. Thoughts?

+1 from me if it's doable in a nice way. I agree with @zah that this would probably be what most people would expect.

[leafo]

So I did two things. I added local back, so you can forward declare names of variables. (doesn't do assignment at the moment).

Secondly, I made it so when you decorate an assignment statement it will pull out the local declarations for all names that aren't in scope yet.

[etandel]

Great! A lot more elegant than assigning nil. =)

But would you consider another name instead of local? While it keeps the underlying Lua semantics clear, it doesn't make much sense since every variable is local. Perhaps JavaScript's var, or something else?

[leafo]

I'm going to stick with local because it's familiar, and it doesn't use up a word (var) that isn't normally reserved.

The tops of my files normally look something like this:

export tree, value, format_error
export Block, RootBlock

local Line, Lines

I think local and export have a nice symmetry.