Julia: Automatic iteration variables

[Tetralux]

Whenever you write a for loop you--more often than not--name an iteration variable.
This does not take much brainpower to do - obviously, we can call it i or e and be done with it.

However, for the most part, you name it the same thing every time.
Because it doesn't matter to you what it's called. What matters is just that you need its value.

So why not have the compiler declare these variables for you with obvious sensible names?
Exactly what these variables would be called is up to you, but I'll highlight what Jonathon Blow's in-development programming language, Jai, calls them: it and it_index.

I would like to point out that while yes, this isn't a necessity in any way, I would suggest that you write enough for loops in any program that this would be a decent quality-of-life improvement to everybody.

TLDR: This would mean that you write this:

for x
    println(it_index, " ", it)
end

and the compiler would could generate this (assuming that you actually use the variables, of course):

for (it_index, it) in enumerate(x)
    println(it_index, " ", it)
end

[yuyichao]

:-1: Implicitly declaring variables that doesn't appear in the code is terrible.

[Tetralux]

@yuyichao Agreed - the compiler could omit them if they are not used.

[johnmyleswhite]

Let's not emulate the bad parts of Perl: http://stackoverflow.com/questions/10487316/best-way-to-iterate-through-a-perl-array

[Tetralux]

@johnmyleswhite I've never liked Perl's way of doing that either; too many sigils for my liking (edit: and $_ _is_ way too hacky).
I would contend that it makes a lot more sense than $_ for the iteration variable though, no?

[yuyichao]

the compiler could omit them if they are not used.

The compiler can already do that. What I mean is that it shouldn't introduce them automatically to begin with. On one thing, AFAICT it does not nest naturally while loops do.

These variables are great for domain specific languages ($@ etc in makefiles for example) and they are useful for perl one liners. I'd even say that a name like @ or _ is better for these since they won't collide with your normal variables. However, AFAICT these features does not really work well when you have a more complex program.

[Tetralux]

@yuyichao While I would be inclined to agree that you don't want variables automatically popping into existence if you can avoid it, this is a logical case - a predictable case; these are variables that you were defining anyway.
If you are going to define them most of the time you use this construct, then I would suggest that it might be useful to make that automatic, and have them either elided when they are not used (which I would guess is easier here?) or only declared when they _are_ used.

With regards to not working very well in a more complex program, I'd be interested to see some discussed examples of that.

[Tetralux]

@yuyichao With regards to loop nesting - that's fine - you would use the shadowing ones inside the inner loop, or if you wanted to access the outer ones from the inner loop, then you would name of one them manually.

[yuyichao]

for x
    for y
         # Where's my `it` in the outer loop?
    end
end

[Tetralux]

The unintentional comment snipe... 😸

[yuyichao]

While I would be inclined to agree that you don't want variables automatically popping into existence if you can avoid it, this is a logical case - a predictable case; these are variables that you were defining anyway.

No I won't define them as these names. This is an argument for why we don't have to write variable declarations or assignment explicitly in a for loop, not for letting the compiler to pick a name that it likes for me.

If you are going to define them most of the time you use this construct, then I would suggest that it might be useful to make that automatic, and have them either elided when they are not used (which I would guess is easier here?) or only declared when they are used.

Because I won't use that name and it's really hard from code searching to figure out where does those variables come from.

[Tetralux]

@yuyichao

Because I won't use that name and it's really hard from code searching to figure out where does those variables come from.

Why would it be hard to figure out where they come from?
It's easy to see that they are compiler inserted variables by looking at the code because they are called it and it_index. That's partly the point. It would be included the manual and it would be fine.

This is an argument for why we don't have to write variable declarations or assignment explicitly in a for loop, not for letting the compiler to pick a name that it likes for me.

The addition of it and it_index strikes me as an extension to things like for x in y; while it wouldn't let you pick what name it will use for these variables, what it picks is constant; it's predictable. It's not ambiguous what these variables are if you have read the simple examples that would be in the manual that demonstrate it; in the body of a for loop, they would always be these variables.

While yes, you can shadow them; you can declare variables with these names yourself, you know what the compiler's going to do with them - and that's if you _chose_ to name a variable it or it_index.

[yuyichao]

Why would it be hard to figure out where they come from?

It does not appear in the code

It's easy to see that they are compiler inserted variables by looking at the code because they are called it and it_index. That's partly the point. It would be included the manual and it would be fine.

No, documenting in the manual is not a good enough reason to include a bad design.

The addition of it and it_index strikes me as an extension to things like for x in y

Except that nothing else in the language introduce new variables meant to be used automatically (gensyms does not count since you cannot access them)

while it wouldn't let you pick what name it will use for these variables

Which is the issue.

what it picks is constant; it's predictable.

Making it worse since it can't be changed.

It's not ambiguous what these variables are if you have read the simple examples that would be in the manual that demonstrate it; in the body of a for loop, they would always be these variables.

Making them effectively reserved word and will cause massive breakage because of this. And again, explaining in the manual is not a good enough execuse.

[johnmyleswhite]

Can I suggest that we don't need to debate this issue? People with commit access can simply vote and we can reach a consensus that way. It's not like there's a ton of ambiguity in the proposal that needs to be fleshed out: this is a purely aesthetic topic that will almost surely not be resolved by prolonged discussion.

[Tetralux]

@johnmyleswhite Provided that I have answered a decent number of the criticisms from those individuals - then yes, I agree.

@yuyichao

[...] is not a good enough reason to include a bad design.

While I do agree that you shouldn't just letting anything remotely interesting into a language, not being able to state what the variables names are going be, is not as important as making for loop nicer to work with by adding automatically-declared variables that don't get declared if you're already using those symbols. See below for further detail.

Except that nothing else in the language introduce new variables meant to be used automatically (gensyms does not count since you cannot access them)

There is no requirement that features that behave differently from those already in the language, cannot be added.

Making them effectively reserved word and will cause massive breakage because of this. And again, explaining in the manual is not a good enough execuse.

You'd put in the manual for completeness. It would not be required in order to understand how it worked since: Using it or it_index as variables inside the body of a for loop, would simply cause the compiler not to declare them if either of them already existed outside the loop.
Massive breakage would therefore also be avoided.

Also, since you can shadow them, or still use them as variable names anyway, it would not be even an "effective" reserved word - not that it would particularly matter if they were. They're not commonly used names.

But, feel free to correct me if I'm wrong. :)

[JeffBezanson]

:-1: from me. This is just unnecessary complexity.

I don't feel it's necessary to cite specific examples of "problems" this would cause, but if a package exported a function called it then you'd be able to call it everywhere except inside a loop. This kind of feature tends to create all sorts of corner cases like this, and adds more bug surface area to the compiler than you'd think.

[stevengj]

I think this can be closed; the overwhelming consensus seems to be against.