largest-series-product corner cases

[petertseng]

As part of the work to have consistency between tracks as in https://github.com/exercism/todo/issues/104 and https://github.com/exercism/todo/issues/13. Comments are in individual commit messages.

[petertseng]

Ah, that's unfortunate. Tests are failing on -Werror because of those Nothings. Going to think about how to deal with that

[petertseng]

Yeah ran locally with -Werror to check, this should be good now. had to add a Nothing that was explicitly Maybe Int

[petertseng]

Going to change that int to be Int -> Maybe Int to avoid all the Just business going on here, I think.

[petertseng]

OK, that's better. Much less churn doing it this way. I saved the old way of doing it at https://github.com/exercism/xhaskell/compare/master...petertseng:lsp-corner-nojust?expand=1 but I think the way it is in this PR is better.

[kytrinyx]

I'm not sure who's around these days who knows Haskell. It looks like @abo64, @NobbZ and @stevejb71 have all commented recently in the Haskell track... would one of you have a moment to review this?

[NobbZ]

I'll take a closer look into this in the next 36 hours.

Katrina Owen [email protected] schrieb am Fr., 29. Jan. 2016 19:58:

I'm not sure who's around these days who knows Haskell. It looks like
@abo64 https://github.com/abo64, @NobbZ https://github.com/NobbZ and
@stevejb71 https://github.com/stevejb71 have all commented recently in
the Haskell track... would one of you have a moment to review this?

—
Reply to this email directly or view it on GitHub
#89 (comment).

[NobbZ]

As far as I can see, the code in the example is idiomatic, the choose of Maybe is reasonable. Only thing I fear is, that someone new to this exercise might fail miserably because he has to return Just x instead of just x ;) I am not aware of how often Maybe is used in the exercises before this already.

Also all the added tests (and the changes to make old ones pass with new code) seem reasonable.

[petertseng]

Reasonble question. I originally tried to answer this question by seeing what has Maybe in it

$ git grep -l Maybe | cut -d/ -f1 | uniq
_test
atbash-cipher
bank-account
binary-search-tree
binary
connect
go-counting
hexadecimal
largest-series-product
linked-list
pov
queen-attack
saddle-points
say
scrabble-score
sgf-parsing
wordy
zipper

If someone follows the order in config.js, then the ones that come before: scrabble-score, binary, atbash-cipher, bank-account, queen-attack, binary-search-tree, hexadecimal

However, I actually realized that it's not necessarily the case that the tests are testing for Maybe -- it could just be an implementation detail of the examples. Indeed, this is true for a lot of them. So I manually look through the list and see which of them have tests involving Maybe (which means the student would have to write code involving Maybe)

• The queen-attack has a test where it passes in Just a board position or Nothing.
• The binary-search-tree problem needs to have a bstLeft and bstRight that return Maybe (BST a).
• bank-account needs Maybe Int for its bank balance. It also seems to require using the IO monad, an interesting choice.

So someone on this exercise either has seen Maybe in a previous exercise (or is skipping around, but in that case they on their own anyway). So I think the specific question of "will someone be confused at the Maybe in here?" is "I think we are OK"

Separately, we may consider somewhere to discuss general questions that rise from the above comment. Possible questions I can think of:

• Should we have exercises designed to ease learners of the language into various concepts of the language? In other words, to what extent shall Exercism try to act as an explicit language tutorial of sorts (rather than just providing an impetus to apply what is learned from an external tutorial)?
• Should there be a limit to the number of new language concepts introduced in each problem?
• To what extent should our test suites test "the fiddly bits" (dealing with errors, etc.) rather than the algorithmic "meat" of the problem?

[petertseng]

Y'all think anything else needs to be done here? Based on the investigation above, I think the Maybe thing is covered earlier so will not be an obstacle, and y'all seem to think everything else is good.

[NobbZ]

I do also think that this can be merged. @kytrinyx

[kytrinyx]

Thanks, merging!