-
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
How to avoid deleting students' work #1133
Comments
As discussed in today's wrap-up meeting:
|
As food for thought, some off-the-top-of-my-head variations on "Just allowing all sorts of edits and merely warning the student somehow" include
All of these come in the varieties:
|
We seem to be in agreement (having also discussed this a little in video calls) that in the short-term we want to remove the not-in-use restriction, even in the absence of any new features. We're happy to just delete code attached to deleted constructors etc. Now that our undo system works reliably (#1086), losing code is a lot less of a disaster that it was previously. Other features which would soften the blow further are general copy-paste of subtrees (#66) as well as copying whole typedefs (#1141), since students could then store a copy of to-be-affected code before performing destructive edits. Even then, we'll eventually want to provide some sort of warning. But I propose that the first pass here not even worry about this, since it will require non-trivial changes to the design of our actions API. |
There are several scenarios where an action other than "delete this node" could cause the student to lose an entire subtree of unbounded size. We have at least:
We currently disable this for in-use typedefs, since the simple way to fix up the program would then be to delete all subtrees mentioning that type or constructor, and we don't want to delete students' work, at least not without making it very clear to them what is happening.EDIT: relaxed in Allow typedef deletions regardless of whether type is in use #1153We disable this for similar reasons to the typedefs case above. It's easier to see how we might fix up the program here (replace variable uses with holes), but it can still have non-local effects, where it would not be immediately obvious what has changed in a large program.EDIT: relaxed in Allow deleting an in-use term definition #1182Scrutinee type changes in match _ with expressions
in Define Primer-the-language #132.Possible solutions
We have discussed a range of ideas for handling this issue:
The text was updated successfully, but these errors were encountered: