Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
pangram 1.4.1.10: Add test case: determine pangram lazily (#795)
* pangram 1.4.1.10: Add test case: determine pangram lazily Fail if the input stream was touched beyond the first occurrence of each letter. Many standard solutions achieve this property without much effort, and some don't. This test case notifies the student that a more optimal solution is within reach. * Disable the test by default While `success-standard` passes this test, and a `String`-based `fail-too-eager` example fails as expected, `success-text` cannot easily succeed, even if is changed into using `Data.Text.Lazy`: One can write a `Data.Text.Lazy as LT`-specific test: describe "isPangram" $ do it "is lazy" $ isPangram (LT.fromChunks ["a...z", undefined]) `shouldBe` True But when the input comes via `fromString :: IsString s => String -> s`, the implementation has little control of the chunking. A failed attempt to circumvent this, newtype ChunkyLazyText = ChunkyLazyText LT.Text instance IsString ChunkyLazyText where fromString = ChunkyLazyText . LT.fromChunks . map (T.pack . return) still causes the `T.pack` invocation on `[undefined]`. And as @bobdalgleish pointed out in [this StackOverflow question][SO], I'd actually end up testing `fromString`. Since "laziness" doesn't mean the same thing for `String` as it does for `Data.Text.Lazy` because chunking works differently, the reliable alternative is to write tests for each implementation. Or, in this case, let string-type specific tests remain commented out. [SO]: https://stackoverflow.com/questions/53784627/testing-laziness-of-isstring-s-s-bool-function * Clarify that this test is mainly intended for String-based solutions
- Loading branch information