I already 100% understand what you're saying. No need to clarify. You're misunderstanding me. >Once you understand that, this confusion makes about as much sen

I already 100% understand what you're saying. No need to clarify. You're misunderstanding me. >Once you understand that, this confusion makes about as much sense as expecting an integer to be "empty". My comment was in reference to the above. An empty number does make sense because of the of 1/0. There is nothing wrong in including a null in a set if there are operations that are illegal. Such operations can't return something so you can use a null to represent the absence of something. This is entirely different from an empty container type. >So, coming from Python, the misunderstanding about why there's no "base case" for char as there is for string is understandable The author is looking for a null value not an empty container type or "base case". I quote: "Haskell has no null definition of type Char," Basically he's looking for the equivalent of "None" in haskell. He has slight confusion in thinking that an empty container type or empty string is equivalent to a "None." Because he literally said he's looking for a null he is indeed talking about all things associated with null. The closest thing to null in Haskell is the maybe monad which is like null but without a runtime exception. His confusion arises because he feels that if in haskell you can do this: stringfunction (x:xs) = ... stringfunction [] = ... Then you should be able to do this: charfunction x = ... charfunction null = ... which is impossible in haskell, so---> I'm saying that similar functionality can be achieved with: charfunction (Just x) = ... charfunction Nothing = ... The above is 100% handling a null, one of the main sources of runtime errors.