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

Adjustments to walk recursion #63

Closed
wants to merge 4 commits into from

Conversation

gaurav-arya
Copy link
Contributor

@gaurav-arya gaurav-arya commented Jan 19, 2023

Adjusts the walk::AbstractWalk interface to naturally support recursion through walk(x, ys...) and deprecates an old fmap signature; resolves #62.

One subtle point: I wanted to leave the recurse first-arg exactly as is which would have made the diff even smaller. However, for the dispatch to work, we needed to restrict the first arg recurse to be an AbstractWalk when implementing walk subtypes, in which case it made more sense to call it outer_walk, or something of that nature. [This is a breaking change for people who have defined custom walks, since custom subtypes of walk will need to make sure to have this dispatch. This leads to IMO the cleanest API, but I could use something more clunky than walk(x, ys...) for the recursive walk and avoid the breaking change if desired. The main point of this PR is to show that something like the recurse closure is not necessary]

@gaurav-arya gaurav-arya changed the title Simplify walk recursion Adjustments to walk recursion Jan 19, 2023
@gaurav-arya
Copy link
Contributor Author

Changing how custom walks are defined would be really breaking for Optimisers, it seems. Closing and trying again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fmap API that accepts an arbitrary walk does not use function f
1 participant