Skip to content
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

Clarify corner-cases better #43

Open
vrom911 opened this issue Oct 1, 2020 · 4 comments
Open

Clarify corner-cases better #43

vrom911 opened this issue Oct 1, 2020 · 4 comments
Labels
chapter1 enhancement New feature or request

Comments

@vrom911
Copy link
Member

vrom911 commented Oct 1, 2020

Mention where we need to be more careful when working with Ints:

  • 0
  • positive
  • negative
  • in some bounds
@vrom911 vrom911 added enhancement New feature or request chapter1 labels Oct 1, 2020
@cardoso-neto
Copy link

cardoso-neto commented Oct 1, 2020

I'm pretty sure that's more of a general programming thing. But if Haskell has interesting ways of dealing with it, it may be useful to highlight it.
Python for example famously allows the following shortcut for my_number < x && my_number > y

y < my_number < x 

which is much more "pythonic" and cool.

@vrom911
Copy link
Member Author

vrom911 commented Oct 2, 2020

Yes, you are right! It just could be useful to mention just so people would setup on thinking more on the corner-cases while working on tasks 🙂

That is a very handy shortcut, indeed. Unfortunately, there is no such feature in Haskell 😞

@grossmeyer
Copy link

I overlooked some of the negative numbers on my first run through of the tests (I didn't run the tests at all until I completed all 10 tasks of Chapter 1), but when I read through the output of the tests, it was readily apparent what cases I was missing and I added them easily enough. Although you could be more explicit in the task text what kinds of tests to expect, I think there is some benefit to be had from having students "solve" the task first and then read through the test output when there are (inevitable) failures, although perhaps it wouldn't hurt to have an explicit suggestion and example of test failure output in the ReadMe itself.

@tquid
Copy link

tquid commented May 13, 2022

At least with the code I had been using:

firstDigit :: Int -> Int
firstDigit n = go n 0
  where
    go :: Int -> Int -> Int
    go 0 n = n
    go n _ = go (n `div` 10) n

The failure mode for the negative integers is to go into an infinite loop. The tests don't detect this, and it can look to a naive user as if the test for big integers is failing. I feel like detecting a loop would be a good part of any unit test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chapter1 enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants