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

Allow typedef deletions regardless of whether type is in use #1153

Merged
merged 4 commits into from
Nov 28, 2023

Conversation

georgefst
Copy link
Contributor

@georgefst georgefst commented Sep 28, 2023

Closes #401.

In the absence of a full feature request, due to this being a fairly straightforward extension of the ideas of #267 with little scope for controversy (by contrast, #402, which I've started some initial work on alongside this, is more exploratory, and I believe will justify a formal feature spec), the behaviour implemented here is as follows:

Deleting a type

  • Replace all uses of the type with a hole: in expressions, types of top-level definitions, and constructor fields
  • Replace all uses of any constructor of the type with a hole
  • Run a full typechecking pass
    • There would otherwise be some awkward cases to patch up, such as modifying metadata in type annotations to reflect the change from KType to KHole
    • We intend to revisit this sort of thing anyway, including potentially running the typechecker on all actions: Run typechecker whenever a typedef changes #399
    • This also automatically cleans up all pattern matches on this type, since we will have set the type of the scrutinee to a hole, and thus the typechecker removes all branches
  • Set selection to empty

Deleting a constructor

  • Replace all uses of the constructor with a hole
  • Remove the corresponding branch from any pattern matches, as well as any appropriate wildcards
  • Set selection to the type

Deleting the nth field of a constructor

  • Remove the nth child from all uses of the constructor
  • Remove the nth child from all patterns featuring the constructor
  • Set selection to the constructor

@georgefst georgefst force-pushed the georgefst/typedef-deletion branch 3 times, most recently from 9f121c1 to f45ba15 Compare October 5, 2023 15:03
@dhess
Copy link
Member

dhess commented Oct 17, 2023

What's the status of this PR? How much work remains before it's ready for review?

@georgefst georgefst requested a review from a team October 17, 2023 14:52
@georgefst
Copy link
Contributor Author

What's the status of this PR? How much work remains before it's ready for review?

None! I just somehow forgot to ask for a review.

primer/src/Primer/App.hs Outdated Show resolved Hide resolved
Comment on lines -465 to +463
forTypeDefConsFieldNode con index id l Editable tydefs defs tdName td =
forTypeDefConsFieldNode con index id l Editable _ _ _ td =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe worth removing these arguments entirely?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. I suspect we may well re-add them at some point, and even with them unused, the uniformity helps in simplifying the definition of Primer.API.availableActions. Ideally we'd probably refactor this to pass around a record for the common fields, in which case we'd be unlikely to complain that not all fields of the record are used in every function which receives it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point. I don't have strong opinions either way.

Comment on lines +725 to +740
updateType = transformM \case
TCon _ n | n == d -> tEmptyHole
e -> pure e
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is somewhat odd to have updateExpr defined above in a let, but updateType defined below in a where. Any particular reason?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, but we mostly use where in the other cases, but updateExpr can't go there because then def would be out of scope. It's a bit weird, but I don't think it's worth changing.

primer/src/Primer/App.hs Outdated Show resolved Hide resolved
Comment on lines 876 to 897
unit_DeleteTypeDef :: Assertion
unit_DeleteTypeDef = progActionTest
( defaultProgEditableTypeDefs
$ sequence
[ do
x <- emptyHole `ann` (tcon tT `tapp` tcon (tcn "Bool") `tapp` tEmptyHole)
astDef "def" x <$> tEmptyHole
]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be better to also use the type's constructors at term level, both as constructors and as patterns in a case

Comment on lines 1100 to 1143
unit_DeleteCon :: Assertion
unit_DeleteCon = progActionTest
( defaultProgEditableTypeDefs
$ sequence
[ do
x <-
case_
(emptyHole `ann` (tcon tT `tapp` tcon (tcn "Bool") `tapp` tcon (tcn "Int")))
[ branch cA [("x", Nothing), ("y", Nothing), ("z", Nothing)] emptyHole
, branch cB [("s", Nothing), ("t", Nothing)] emptyHole
]
astDef "def" x <$> tEmptyHole
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we also use cA as a constructor? (Maybe in the RHS of the cB branch)

Copy link
Contributor

@brprice brprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good. I have a handful of small comments and one large one that has triggered me to put "Request changes": the issue about scoping when deleting a field (#1153 (comment))

@georgefst georgefst force-pushed the georgefst/typedef-deletion branch from f45ba15 to ebafd4f Compare October 19, 2023 17:27
I haven't found any particular test case which is affected by this, but it seems safer, and will also make it easier to factor out this code.

This appears to be an oversight from `257cb77: feat: Implement actions for editing type parameter kinds`.

Signed-off-by: George Thomas <[email protected]>
@georgefst georgefst force-pushed the georgefst/typedef-deletion branch from ebafd4f to e906f3a Compare November 27, 2023 14:14
@georgefst
Copy link
Contributor Author

What's the status of this PR? How much work remains before it's ready for review?

None! I just somehow forgot to ask for a review.

Actually, I think it was because I had intended to add a few more tests. I'm just finishing these now, along with @brprice's suggested tests.

@georgefst georgefst force-pushed the georgefst/typedef-deletion branch from e906f3a to 81f235a Compare November 28, 2023 10:29
@georgefst georgefst enabled auto-merge November 28, 2023 10:29
This includes fixing up expressions utilising the deleted type/constructor/field so that they still make sense. Mostly this involves replacing subexpressions with holes.

Note that this does not yet include deleting type parameters, which we still cannot modify at all when the type is in use. But we aim to relax this restriction as well shortly.

We add a unit tests for each action. Note that we didn't actually have any for the old behaviour, due to time constraints when that was implemented. Although the `tasty_available_actions_accepted` property test caught a lot of issues for us.

Signed-off-by: George Thomas <[email protected]>
@georgefst georgefst force-pushed the georgefst/typedef-deletion branch from 81f235a to 26aaa83 Compare November 28, 2023 11:28
@georgefst georgefst added this pull request to the merge queue Nov 28, 2023
Merged via the queue into main with commit 4db7bf8 Nov 28, 2023
2 checks passed
@georgefst georgefst deleted the georgefst/typedef-deletion branch November 28, 2023 11:43
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.

Editable typedefs: deletion
3 participants