Add POV exercise

[senekor]

Co-authored-by: devcyjung [email protected]

[senekor]

supersedes #2077

I already had a lot of back-and-forth with the original author. I guess they tapped out at some point 🙁 I pinged them after a month and still haven't heard back a second month later.

I think this is a pretty cool exercise and unique on the track. No other exercise deals with mutating trees. So I want to get it over the finish line. I made sure to keep the original author in .meta/config.json. Once we squash-merge, the PR description will become the commit message, so the Co-authored-by trailer will attribute the commit to them as well.

I did change quite a bit of stuff though. The API design was geared towards immutability before, I changed that to allow an implementation without unnecessary allocations. I think the mutable API is not only important because of performance, but also because cloning everything kinda takes away the challenge unique to Rust in this case. That would be a missed opportunity for special learning moments in my opinion.

[ellnix]

Unfortunately I don't think I have enough knowledge of rust to solve this mutably. I couldn't think of a way to implement the tree swapping that the borrow checker approved of. Looking at example.rs it looks like I had to mem::swap which I haven't done in ages, if ever, so I can't say I reached for it.

I agree that it would be much less interesting if you could clone everything. In it's current state this is a very short exercise that requires you to know the borrow checker well and know some graph theory. I think this would be one of the best exercises on the track.

I only have some minor feedback:

• path_to could maybe be renamed to path_between
• path_to only presents a challenge of implementing a tree search algorithm, which pov_from also requires you to implement
  • as a twist, it might make sense to make path_to immutable to prevent the student from reusing pov_from and having them implement a tree search for two nodes from the root and returning the path between them

I'll approve this so that you have the discretion to disagree with those points and merge 😄

[senekor]

path_to could maybe be renamed to path_between

That's a great point. The name comes from problem-specifications, so I didn't question it. But we can just rename it. path_between makes much more sense.

path_to only presents a challenge of implementing a tree search algorithm, which pov_from also requires you to implement

as a twist, it might make sense to make path_to immutable to prevent the student from reusing pov_from and having them implement a tree search for two nodes from the root and returning the path between them

Also a great thought. I think in this case it's kind of a feature that path_to is easy to implement, based on pov_from. The point is basically to show to the user: "Look how easy it is to find a path, now that we can reparent the tree!"

So, I think I'll leave that part as-is.

[senekor]

Thanks for the review!