Open dloscutoff opened 7 months ago
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.
A couple of different, maybe mutually exclusive ideas about automatically assigning variables within loops:
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 inF
loops;j
is currently unused. Cons: global variables wouldn't play well with recursion; default value ofi
as0
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).