Skip to content

Wingman feature request: Support for tactic subgoals via let #2002

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

Closed
s-zeng opened this issue Jul 6, 2021 · 5 comments · Fixed by #2160
Closed

Wingman feature request: Support for tactic subgoals via let #2002

s-zeng opened this issue Jul 6, 2021 · 5 comments · Fixed by #2160
Assignees
Labels

Comments

@s-zeng
Copy link

s-zeng commented Jul 6, 2021

Feature request: there should be a tactic that allows the user to introduce arbitrary subgoals. Currently, subgoals are only introduced via destruct_all or similar tactics. But in general some subgoals are desired as helpers that cannot be produced from destruct and it's variants, so we should have a define tactic (or something similar) that let's use make arbitrary subgoals. For example, given:

_ :: a

and using a tactic define b :: b, we should be able to produce:

let b = (_ :: b) in (_ :: a)

This then should give us b as a subgoal, which when completed gives us b :: b as a hypothesis for completing the a goal.

@s-zeng s-zeng changed the title Wingman: s Wingman: Support for subgoals via let Jul 6, 2021
@s-zeng s-zeng changed the title Wingman: Support for subgoals via let Wingman feature request: Support for tactic subgoals via let Jul 6, 2021
@isovector isovector self-assigned this Jul 6, 2021
@isovector
Copy link
Collaborator

isovector commented Jul 6, 2021

Unfortunately, our parsing capabilities aren't good enough to allow for arbitrary types, and this unlikely to change anytime in the near future.

So what could we do instead? Maybe just a bare

define b

that then gets a fresh unification variable as its type. Subsequent tactics could unify that type. What do you think?

Also, it seems like we should be able to define multiple things here, so define a b c would produce

let a = (_ :: a0)
    b = (_ :: b0)
    c = (_ :: c0)
 in _

@isovector
Copy link
Collaborator

There's also the question of hole ordering. Should the main goal come first, or the bindings?

@isovector
Copy link
Collaborator

@s-zeng any opinions on this?

@s-zeng
Copy link
Author

s-zeng commented Jul 16, 2021

Sorry for missing this! I'm of the mind that if we want the things we define to be usable hypotheses for the main goal, we should have the define holes come first.

But that needs us to update the refinement type in other places it appears, which doesn't happen right now as far as I can tell. For instance if we refine the non-function hole we get from unary, the function hole isn't updated to match it.

If we can get that to happen, then I would be quite happy. But I'm not sure how feasible that is, or how to go about implementing it

@isovector
Copy link
Collaborator

if we refine the non-function hole we get from unary, the function hole isn't updated to match it.

Is it not? It should be!

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

Successfully merging a pull request may close this issue.

2 participants