Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Simplify the semantics of Lambda.free_variables and Lambda.subst #1606
The patch is larger than can be expected for this kind of change because I changed
The main reason for the change is that it is useful (and the cleanest way) for a patch about let-rec compilation.
I'd like to highlight a particular case about
Also this code might be slightly slower, but I couldn't notice the difference.
The patch seems correct from a distance, but I have several naive questions:
Now to more precise comments:
As long as you use only
Usually, when the type is not too large, I find it less error-prone to rewrite the whole recursion. If you want the function to be properly maintainable, you often need to list all the cases, and there is a very small gain from using a generic iterator. Especially if you want the iterator to be generic enough to provide both a way to propagate information down and up, which is needed for instance for the substitution.
My conclusion for that would be that there are not enough traversals similar enough to benefit from introduction of specific generic function. But there are a few functions in Simplif that could probably be rewritten with iter and may benefit from it. I can take a look into it.
For the specific questions:
I removed free_ids, inlined it into free_methods and moved it to translclass. It used to consider v as a free method in
I took the opportunity to rename Lambda.iter into something that doesn't suggest that the function recursively traverse the expression. It might not be the best name, but it clearly prevent the confusion.
gasche left a comment
I reviewed the PR again and I believe it is correct.
I don't know whether we should be careful about breaking the interface lambda.mli -- it may affect users of compiler-libs -- but in absence of a recognized need to preserve it, I think that maintaining the old interfaces for hamper maintainability more than they would help.
@chambart, please take care of merging (and rebasing if necessary, etc.). I think that Changes entry detailing the API changes could make sense, in the Internals category, but that's your choice.