-
Notifications
You must be signed in to change notification settings - Fork 1
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
Remove more holes automatically #7
Comments
One approach is to remove the hole regardless, and then make downstream insert holes if they break. Consider |
What's the status of this issue wrt the new smart holes implementation? |
Essentially unchanged. We attempt to remove holes, but the implementation is somewhat ad-hoc and should be improved to both be more general and more intuitive. Some particular issues we currently have
However, I still don't know how to remove all(/most) "pointless" things whilst not making it awkward to intentionally create something like Perhaps we need to rethink the decision to operate only on the AST, and instead track whether holes were automatically created? |
It would be great if we could reach a point where the manual However, while tring to work out exactly when the action is offered in the first place (the |
I agree (modulo one concern). The issue here is how to do it efficiently, and potentially how to choose which subset of holes to finish if there are conflicts (I haven't thought about whether this is possible). My one concern here is that there may be holes that the student wants to keep around for some reason -- perhaps it contains a type-correct term but it is semantically wrong. This however is somewhat orthogonal, and maybe should be dealt with by adding a flag on holes "student-defined"/"automatically-created".
Yes, we simply offer it at any hole. I have not thought about how to detect whether it is a sensible action efficiently. |
We don't (even after hackworthltd/vonnegut#175) remove holes such as
{? Succ ?} Zero
because we don't have enough information to see if the hole is "finishable" at the point we handle the hole. In general, if a hole is in a synthesis position, we don't know where else downstream it is being referred to, so we dare not change its type.
I don't know how to do better here!
I also don't know how common this situation is in practice, so have no idea if this should be high priority or not.
The text was updated successfully, but these errors were encountered: