Overly general type signatures that violate contextual constraints do not raise errors

[arendsee]

In the flu case study of commit d6c2aba, in the function definition:

plotCladeTree :: FluConfig -> RootedTree Str e (a, Clade) -> ()
plotCladeTree config = plotTree config@treefile . mapLeaf setLeafName 

where plotTree, mapLeaf, and setLeafName have the following signatures:

plotTree :: Filename -> RootedTree n Real Str -> ()
setLeafName :: (JsonObj, Sequence) -> Str
mapLeaf :: (l -> l') -> RootedTree n e l -> RootedTree n e l'

In the top-level signature definition for plotCladeTree, there are two generic types, e and a. However, these types will be inferred to be Real and (JsonObj, Sequence), respectively.

This code does not raise an error, but it probably should. e and a are not really free here, they are constrained to specific types. In Haskell, this code would raise "rigid type value" errors. That is, the general type requested for each variable violates contextual constraints placed on the variables.