Mark partial functions as such

[Bardur Arantsson]

On 31/08/2018 21.14, Tikhon Jelvis wrote:
> This is a question of documentation, not type design. You don't have to
> consider what exceptions your transitive dependencies might throw—you
> need to understand what inputs *do* cause your function to fail. If you
> use head in a safe way or have a call to error in an unreachable case,
> you shouldn't say anything. On the other hand, if your function fails
> when the inputs aren't relatively prime, you should document this
> regardless of whether the failure is an exception you throw explicitly,
> a result of a partial pattern match or a division by zero four layers of
> indirection away.
> 
> I definitely expect the author of a function to understand what inputs
> cause that function to fail. If you don't understand this, you simply
> don't understand the code you wrote. (Luckily, QuickCheck will probably
> find any edge cases you missed when writing the function.)
> 
> Thinking about it a bit more, there's nothing specific to exceptions
> here. If your code loops forever when the lengths of the inputs sum to a
> multiple of seven, that's pretty handy to know from the documentation! 
> 
> I would also expect the same style of documentation even for errors
> expressed in the types with whatever your favorite generalization of
> Either happens to be.
> 

Oh, of course, these are good points. My point was simply that it's
often a little bit complicated to *document* this in a simple easy to
understand way.

Regards,