on 28-Jun-2020 (Sun)

The good news is there is something you can do to get more help from GHC on avoiding partial functions. If we turn all warnings on with the Wall flag in our REPL or in our build configuration (such as with Cabal — more on that later), then GHC will let us know when we’re not handling all cases:

CommerceContext loads the connection string from a configuration

file — this is a trap. It causes every new CommerceContext to read the configuration

file, even though the configuration file typically doesn’t change while

an application is running. A CommerceContext shouldn’t contain a hard-coded

connection string, but neither should it load a configuration value from the

configuration system.

Mary loaded the connection string from the configuration file from within the CommerceContext

class (shown in listing 2.2). From the perspective of its consumers, the

dependency on this configuration value is completely hidden. As we alluded to

when discussing listing 2.2, this implicitness contains a trap.

Although the ability to configure a compiled application is important, only the

finished application should rely on configuration files. It’s more flexible for reusable

libraries to be imperatively configurable by their callers, instead of reading

configuration files themselves. In the end, the ultimate caller is the application’s

entry point. At that point, all relevant configuration data can be read from a configuration

file directly at startup and fed to the underlying libraries as needed.

We want the configuration that CommerceContext requires to be explicit.

A few things to keep in mind about writing Ord instances: First, it is wise to ensure that your Ord instances agree with your Eq instances, whether the Eq instances are derived or manually written. If x == y , then compare x y should return EQ . Also, you want your Ord in- stances to define a sensible total order. You ensure this in part by covering all cases and not writing partial instances, as we noted above with Eq. In general, your Ord instance should be written such that, when compare x y returns LT, then compare y x returns GT.

The methods and operations are in the typeclasses, and so we get more utility by specifying typeclass constraints. If your types are more general than your terms are, then you need to constrain your types with the typeclasses that provide the operations you want to use.

Usually, you want the minimally sufficient set of constraints on all your functions — so we would use Eq instead of Ord if the above example was “real” code

Concrete types imply all the typeclasses they provide

ne of the nice things about parametricity and type- classes is that you are being explicit about what you mean to do with your data which means you are less likely to make a mistake. Int is a big datatype with many inhabitants and many typeclasses and opera- tions defined for it — it could be easy to make a function that does something unintended. Whereas if we were to write a function, even if we had Int values in mind for it, which used a polymorphic type constrained by the typeclass instances we wanted, we could ensure we only used the operations we intended. This isn’t a panacea, but it can be worth avoiding concrete types for these (and other) reasons sometimes.

Direito Administra