Binary Search Tree: add test cases for `bstRight`, `bstLeft` about haskell

[github-actions]

Hello. Thanks for opening an issue on Exercism. We are currently in a phase of our journey where we have paused community contributions to allow us to take a breather and redesign our community model. You can learn more in this blog post. As such, all issues and PRs in this repository are being automatically closed.

That doesn't mean we're not interested in your ideas, or that if you're stuck on something we don't want to help. The best place to discuss things is with our community on the Exercism Community Forum. You can use this link to copy this into a new topic there.

---

Note: If this issue has been pre-approved, please link back to this issue on the forum thread and a maintainer or staff member will reopen it.

[petertseng]

I find this persuasive. This has my support for the Haskell track.

If this were to be represented in problem-specifications, problem-specifications would need a bit of a rewrite such that it tests the result of a specific sequence of left/right, and then two possible expectations:

• JSON's null corresponds to Haskell's Nothing
• JSON's {"data": null, "left": null, "right": null} corresponds to Haskell's Just Tip/Just Leaf (whatever the student decided to call that case)

I cannot predict whether this distinction is sufficiently useful in other languages for such a problem-specifications proposal to gain sufficient support. I pre-emptively pledge my support for it if it is ever made in the future, but I cannot force anyone to make such a proposal.

How about what such a test would look like in Haskell? One angle I would like to make sure is considered is the student who writes the erroneous case (bstLeft (Node _ Nil _) = Nothing) and their experience upon seeing that the test fails. Is it obvious to them what they need to do? A student who knows to let the types guide them could realise that there is in fact only one reasonable way to make it work, but I can't predict how many students do in fact know to let the types guide them. They may instead get confused and say "but this obviously doesn't have a left so there's no valid value I can give here". If there is a way to guide such a student to the correct answer, that would be good. Since this is all speculation, I would not require that such a thing be present in a first pull request adding these tests, but it's something to think about more as students start experiencing that test.

[MatthijsBlom]

I cannot predict whether this distinction is sufficiently useful in other languages for such a problem-specifications proposal to gain sufficient support.

I expect not, but I have asked on the forum just in case.

How about what such a test would look like in Haskell?

Two possibilities, essentially:

it "retrieves branches even when they are empty" $ do
  let t = singleton int4

  -- too mystifying?
  bstLeft t `shouldNotBe` Nothing
  bstRight t `shouldNotBe` Nothing

  -- and/or

  -- too obvious?
  bstLeft t `shouldBe` Just empty
  bstRight t `shouldBe` Just empty

We already force implementing Eq (through the "empty list to tree" test), so comparing to empty is possible.

I somewhat expect the Just empty test to result in students writing

bstLeft :: BST a -> Maybe (BST a)
bstLeft (Node _ Nil _) = Just Nil
bstLeft (Node _ l   _) = Just l
bstLeft _              = Nothing

[petertseng]

There is still a possibility a student writes that (Node _ Nil _) case even with shouldNotBe Nothing, though I think a smaller chance.

If there were a readily-available statistic that tells what proportion of students start the exercise but never submit it (and provides historical data of that statistic), then that would make it possible to see whether students are giving up at an increased rate due to the added test. If such data isn't available, that seems like something that would be generally useful to add, not just for this track and this specific test.

For guidance for students who are confused by that test, perhaps a comment in the test file?

[MatthijsBlom]

If there were a readily-available statistic that tells what proportion of students start the exercise but never submit it

An approximation exists: the new track impact page. Data will be slow though: apparently this exercise is started less than once per day.

For guidance for students who are confused by that test, perhaps a comment in the test file?

hints.md exists for this purpose, I think.