dloscutoff/pip

Automatic loop variables

Opened this issue · 3 comments

A couple of different, maybe mutually exclusive ideas about automatically assigning variables within loops:

  1. For any type of loop, assign the iteration number (0, 1, 2, ...) to some variable automatically.
  2. For F specifically, change the syntax to not require an explicit loop variable and assign the iteration value to some variable automatically. (This would be compatibility-breaking.)

In both cases, nested loops would need to use different variables. Thoughts on what variables to use:

  • ijk. Pros: stereotypical loop variables, already often used in F loops; j is currently unused. Cons: global variables wouldn't play well with recursion; default value of i as 0 is often useful, might not want to overwrite that the moment a loop comes into the picture.
  • edc. Pros: hardly ever used. Cons: they do have a clear meaning already; that and the reverse alphabetical order could be confusing; local variables are harder to use in map/filter functions; unclear what to do if loops are nested more than five deep (though that seems pretty unlikely).

After looking at some code-golf solutions, it seems like both changes would be helpful in some situations, but the for-loop change would be helpful more often. One issue there is that the destructuring for-loop header syntax F[abc]l{} would have to go away. But I don't think I've ever actually used that, and perhaps there could be a different command that still allowed it.

Question: Should e, d, etc. from loops overwrite function arguments, or not? E.g. if we have loops nested three levels deep, should the third level assign its iteration count to c 1) under all circumstances, or 2) only when the current function received fewer than three arguments?

(Whichever behavior is the default, there could conceivably be a flag to use the opposite behavior. And there could conceivably be a warning message whenever there's a conflict.)

I looked at a bunch of existing Pip golf solutions, and I believe not one of them would be harmed by loops setting local variables automatically. (There's a couple that are close, such as one that takes three arguments and has a doubly-nested loop.) So to answer the above question, I'd say do whatever's easiest to implement, and if it ever becomes a problem in the future, we can add options for working around it.