3 ms·

I use a parser to check for a non empty list return. It’s called a unit test. All joking aside, what is the practical difference or benefit here to testing?

crazydoggers 6y ago
No one genuinely has an answer to this? I get that we’re talking about Haskell here which is compiled. But why wouldn’t we talk about running the code through unit tests. For example the article talks about given function that requires a number that must be between one and five... and then goes on to specify specific grammar rules. How is that better than simply typing that up in a test. And by simply running test suites you eliminate issues with bugs in your parser system. What am I missing?
- ghostwriter 6y ago
  When you have a non-emptiness property on a type, the compiler can guarantee you that all current and future occurences of values of that type in the system will be interacted consistently with the specified non-empty property. Or in other words, the accent is moved from the limited set of units that you are able (and willing) to test to the invariants that will be held for all occurences of the type at all times, regardless of an unlimited number of units that are willing to use them.
  - crazydoggers 6y ago
    How does one guarantee that for all values? If we’re talking about a parser, wouldn’t it need to test all the values? And if your not testing all the values, aside from simple cases, it’s not something that could just be computed (np, halting problem etc)... so wouldn’t the parser still just need to test some preset number of values? I guess maybe we’re talking kind of like a prebaked in set of unit tests for certain circumstances?
valenterry 6y ago
Very simple. Say you have a user that inputs a list. And then you have another function somewhere in the code, that takes a list, sorts it and uses the max value to send a notification email. If it's done your way, then you'll have to add an assertion in that function, such as if(input_list.length < 1) explode("Bug! Bug! You can't call me with an empty list") And you will have to write multiple unit tests _each time_ you call this function from somewhere, to make sure it's not called with an empty list. If you use a compiler... all of this goes away. The function just expects you to give it a non-empty list and if you don't the code just doesn't compile. Less code to maintain = win. The price you pay for this is learning, understanding and using a more advanced typesystem. That's not a small price to pay. Pick your poison.
- crazydoggers 6y ago
  Your example isn’t even what the articles attempt to suggest, and indeed, it’s not even possible, since there’s no way to ensure that the program passes non empty lists at compile. For example the grandparent article compares these validateNonEmpty :: [a] -> IO () validateNonEmpty (_:_) = pure () validateNonEmpty [] = throwIO $ userError "list cannot be empty" parseNonEmpty :: [a] -> IO (NonEmpty a) parseNonEmpty (x:xs) = pure (x:|xs) parseNonEmpty [] = throwIO $ userError "list cannot be empty" He then states “Both of these functions check the same thing, but parseNonEmpty gives the caller access to the information it learned, while validateNonEmpty just throws it away.” But the caller still needs to deal with the empty type. It’s just moved it up higher in the code. Which makes checking easier. He’s referring to this as “parsing” “parseNonEmpty is a perfectly cromulent parser: it parses lists into non-empty lists, signaling failure by terminating the program with an error message” The parent article however seems to want to take this further, but again, to make use of this as suggested by actually parsing still would require unit tests. A compiler can’t solve the problem of preventing the class of bug you’re talking about, hence why there always needs to be some code that handles cases like empty files or lists etc. To understand why check out the halting problem: https://cs.stackexchange.com/questions/72014/what-cannot-be-proven-at-compile-time-about-a-computer-program https://cs.stackexchange.com/questions/72014/what-cannot-be-... https://en.m.wikipedia.org/wiki/Halting_problem https://en.m.wikipedia.org/wiki/Halting_problem

crazydoggers 6y ago

No one genuinely has an answer to this? I get that we’re talking about Haskell here which is compiled. But why wouldn’t we talk about running the code through unit tests. For example the article talks about given function that requires a number that must be between one and five... and then goes on to specify specific grammar rules. How is that better than simply typing that up in a test. And by simply running test suites you eliminate issues with bugs in your parser system. What am I missing?

ghostwriter 6y ago
When you have a non-emptiness property on a type, the compiler can guarantee you that all current and future occurences of values of that type in the system will be interacted consistently with the specified non-empty property. Or in other words, the accent is moved from the limited set of units that you are able (and willing) to test to the invariants that will be held for all occurences of the type at all times, regardless of an unlimited number of units that are willing to use them.
- crazydoggers 6y ago
  How does one guarantee that for all values? If we’re talking about a parser, wouldn’t it need to test all the values? And if your not testing all the values, aside from simple cases, it’s not something that could just be computed (np, halting problem etc)... so wouldn’t the parser still just need to test some preset number of values? I guess maybe we’re talking kind of like a prebaked in set of unit tests for certain circumstances?

valenterry 6y ago

Very simple. Say you have a user that inputs a list. And then you have another function somewhere in the code, that takes a list, sorts it and uses the max value to send a notification email. If it's done your way, then you'll have to add an assertion in that function, such as if(input_list.length < 1) explode("Bug! Bug! You can't call me with an empty list") And you will have to write multiple unit tests _each time_ you call this function from somewhere, to make sure it's not called with an empty list. If you use a compiler... all of this goes away. The function just expects you to give it a non-empty list and if you don't the code just doesn't compile. Less code to maintain = win. The price you pay for this is learning, understanding and using a more advanced typesystem. That's not a small price to pay. Pick your poison.

crazydoggers 6y ago
Your example isn’t even what the articles attempt to suggest, and indeed, it’s not even possible, since there’s no way to ensure that the program passes non empty lists at compile. For example the grandparent article compares these validateNonEmpty :: [a] -> IO () validateNonEmpty (_:_) = pure () validateNonEmpty [] = throwIO $ userError "list cannot be empty" parseNonEmpty :: [a] -> IO (NonEmpty a) parseNonEmpty (x:xs) = pure (x:|xs) parseNonEmpty [] = throwIO $ userError "list cannot be empty" He then states “Both of these functions check the same thing, but parseNonEmpty gives the caller access to the information it learned, while validateNonEmpty just throws it away.” But the caller still needs to deal with the empty type. It’s just moved it up higher in the code. Which makes checking easier. He’s referring to this as “parsing” “parseNonEmpty is a perfectly cromulent parser: it parses lists into non-empty lists, signaling failure by terminating the program with an error message” The parent article however seems to want to take this further, but again, to make use of this as suggested by actually parsing still would require unit tests. A compiler can’t solve the problem of preventing the class of bug you’re talking about, hence why there always needs to be some code that handles cases like empty files or lists etc. To understand why check out the halting problem: https://cs.stackexchange.com/questions/72014/what-cannot-be-proven-at-compile-time-about-a-computer-program https://cs.stackexchange.com/questions/72014/what-cannot-be-... https://en.m.wikipedia.org/wiki/Halting_problem https://en.m.wikipedia.org/wiki/Halting_problem