RichConditional (hackage):   [Index]  Package maintainers  For package maintainers and hackage trustees  Candidates    Typeclasses for describing "rich conditionals" which accomplish exactly what a classic if/else would but without the use of Bool.  The inspiration is found in dependently typed languages, in which a Bool is seen to be a comparatively pathetic datatype: it carries very little information. A useful test for some condition always introduces new information, but with a classical if/else, this information not known to the compiler because it's lossfully compressed into a Bool.  There is no new technology here, only typeclasses and functions which might make it more convenient to avoid using if/else.  #A motivating example  To demonstrate the point, suppose we defined the following module, in which the constructors of Visitor are not exposed:  We have indicator functions on Visitor, but they don't allow for a useful interface. In the example below, we can't build a user's landing page because we can't get a hold of a User value.  Evidently the Visitor library must provide some way to get a hold of a User from a Visitor, but if it does provide this, then why even bother giving the indicators isLoggedIn and isGuest?  Contrast the above definitions with a Bool-free approach:  Visitor is just Maybe User with a new name, and ifVisitor is just the function maybe with its parameter order shuffled. It provides users of Visitor a way to get a hold of a User for LoggedIn cases without pattern matching on Visitor directly. It can be used to implement a well factored version of the landing page example:  #Use of RichConditional  This modification of the above examples shows how RichConditional could be used:
Keywords: control|library|mit