Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic loop variables #70

Open
dloscutoff opened this issue Mar 17, 2024 · 3 comments
Open

Automatic loop variables #70

dloscutoff opened this issue Mar 17, 2024 · 3 comments
Labels
brainstorming Less of an issue, more of a place to kick around ideas. compatibility-breaking Making this change would break backward compatibility. enhancement

Comments

@dloscutoff
Copy link
Owner

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).
@dloscutoff dloscutoff added enhancement brainstorming Less of an issue, more of a place to kick around ideas. compatibility-breaking Making this change would break backward compatibility. labels Mar 17, 2024
@dloscutoff
Copy link
Owner Author

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.

@dloscutoff
Copy link
Owner Author

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.)

@dloscutoff
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
brainstorming Less of an issue, more of a place to kick around ideas. compatibility-breaking Making this change would break backward compatibility. enhancement
Projects
None yet
Development

No branches or pull requests

1 participant