3 ms·

How does it handle the case where different packages provide conflicting definitions for any of these things?

• dllthomas 10y ago
  This can break things (at compile time, unless you errantly mark something with an OVERLAPS pragma), which is why it's recommended that instances live where the type is defined or where the typeclass is defined. Instances defined elsewhere are known as "orphan instances", and trigger a warning (which you can disable) in GHC. Edited to add: Note that the above applies mostly to libraries. There's not really a downside to defining orphan instances in an application so long as you guarantee consistency (and the best way to do that, IME, is to put all your orphans in one place, with only that file marked -fno-warn-orphans).
• clusmore 10y ago
  What exactly do you mean by conflicting? Remember that the types, typeclasses and function implementations are all namespaced, so name collisions here are fine. The only problem occurs when you define multiple instances for a type and a typeclass (e.g. Int is a Monoid as a sum and separately Int is a Monoid as a product) and you attempt to import both instances into the same module, called Overlapping Instances. But if the usage of the overlapping instances is not ambiguous it wont' cause any problems. Even the following is perfectly fine: -- sum.hs module Sum where instance Monoid Int where mappend = (+) mempty = 0 ten :: Int ten = mconcat [1..4] -- product.hs module Product where instance Monoid Int where mappend = (*) mempty = 1 twentyfour :: Int twentyfour = mconcat [1..4] -- usage.hs import Sum import Product twohundredforty :: Int twohundredforty = ten * twentyfour
  • deleted 10y ago
    [deleted]